/irc-logs / freenode / #whatwg / 2012-03-29 / end

Options:

1. # Session Start: Thu Mar 29 00:00:00 2012
2. # Session Ident: #whatwg
3. # [00:02] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
4. # [00:02] * Quits: erichynds (~ehynds@64.206.121.41)
5. # [00:03] * Quits: Lachy (~Lachy@cm-84.215.13.244.getinternet.no) (Quit: Computer has gone to sleep.)
6. # [00:08] * Quits: sedovsek (~robert@93-103-90-17.dynamic.t-2.net) (Quit: sedovsek)
7. # [00:10] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
8. # [00:10] * Joins: Sirisian (~Sirisian@adsl-69-208-90-211.dsl.klmzmi.ameritech.net)
9. # [00:11] * jonlee is now known as jonlee|afk
10. # [00:12] * jwalden sees the soccer ball in Firefox in F15
11. # [00:12] <jwalden> guess I have enough fonts installed for it
12. # [00:14] * jonlee|afk is now known as jonlee
13. # [00:19] * Quits: nessy (Adium@nat/google/x-owfyxxcpqsxznfdl) (Quit: Leaving.)
14. # [00:19] <zewt> TabAtkins: that's not convincing at all, because it assumes incorrectly that views are only ever used for creating data that you hand off to WebGL
15. # [00:19] <zewt> that's just obviously false
16. # [00:21] <gsnedders> See: pdf.js.
17. # [00:21] <zewt> the solution is to define both these views and all WebGL access as little endian, say "if you're big-endian, you're on your own", and then ignore big endian because big endian is dead
18. # [00:22] <TabAtkins> Using a DataView, particularly once it's been expanded to be as easy to use as the other array views, seems to be the preferred answer.
19. # [00:22] * Quits: jryans (~jryans@24-155-144-5.static.grandenetworks.net) (Quit: Leaving...)
20. # [00:22] <zewt> dataview is completely irrelevant
21. # [00:22] <TabAtkins> Why so?
22. # [00:22] <zewt> views exist, so people will use them; dataview existing doesn't change taht
23. # [00:22] <zewt> also that
24. # [00:23] <zewt> we can't remove alert() just because there are other ways to display messages; people use alert
25. # [00:23] <TabAtkins> DataView is meant to be *the* way to send/receive from servers.
26. # [00:23] <zewt> but it *isn't*
27. # [00:23] <TabAtkins> Right now, sure. Because DataView wasn't widely implemented.
28. # [00:23] <zewt> views exist, and people use them (and I'll use them, because it's much nicer to have an array view of an array instead of calling a function)
29. # [00:23] <zewt> doesn't matter--views still exist and will still be used
30. # [00:24] * Quits: Neocortex (~niels@82-170-160-25.ip.telfort.nl) (Remote host closed the connection)
31. # [00:24] <TabAtkins> And so any advice about how to use TypedArrays *today* can't reasonably tell people to use DataViews.
32. # [00:24] <gsnedders> zewt: Big endian is *not* dead because typed arrays are done for things apart from WebGL. pdf.js, for example.
33. # [00:24] <TabAtkins> The "array view of an array" thing is the "once DataViews are fixed up to be as convenient as the other arrays" thing.
34. # [00:24] <zewt> gsnedders: find me a marketshare % of big endian systems and tell me it's not dead, heh
35. # [00:24] * Joins: Neocortex (~niels@82-170-160-25.ip.telfort.nl)
36. # [00:24] <zewt> (of big endian systems that implement modern APIs, including ArrayBuffer and WebGL)
37. # [00:25] <TabAtkins> From what I understand, a number of file formats (that you may want to read with an arraybuffer) are big-endian.
38. # [00:25] <gsnedders> zewt: Well, of BE systems, yes, but file formats are still often BE.
39. # [00:25] <smaug____> aklein: ping
40. # [00:25] <zewt> (why is Firefox's address bar autocomplete so utterly broken? I type "typed arrays", hit enter; I see that it had the typed array spec selected when I was at "typed", but then it decided to jump to some random google search when I finished typing)
41. # [00:25] <aklein> smaug____: pong
42. # [00:26] <zewt> gsnedders: file formats aren't the issue (there *should* be explicitly big-endian views)
43. # [00:26] <smaug____> aklein: about attribute filters
44. # [00:26] <smaug____> aklein: sicking suggested that attribute filter applies only to non-namespaced attributes
45. # [00:26] <jgraham> TabAtkins: Surely you have done the web thing long enough to know that if there are two ways to do something and one is wrong, authors will do the wrong way 80% of the time, the right way 10% and invent an entirely new and wrong way 10%
46. # [00:26] <smaug____> aklein: what do you think about that
47. # [00:26] <zewt> TabAtkins: DataView is an inherently less convenient API than views, for accessing arrays
48. # [00:27] <TabAtkins> I'd say the percentages are more balanced, overall. They don't *instinctively* reach for the bad one. They just do it randomly, like a gas filling a room. Brownian motion and all that.
49. # [00:27] <TabAtkins> zewt: Yes. Right now.
50. # [00:27] <zewt> jgraham: (I object to the idea that accessing arrays inside a file format via views is "wrong"; it's the right, clean thing to do, and the "design" is wrong)
51. # [00:27] * Quits: tomasf (~tom@2002:55e5:dbb7:0:14c9:2676:fdeb:83ec) (Quit: tomasf)
52. # [00:27] <zewt> TabAtkins: what is "right now"? who is proposing changes to it?
53. # [00:27] <smaug____> aklein: I don't care too much, but would could change my patch (which sicking is reviewing) if you agree with the change
54. # [00:27] * Joins: tomasf (~tom@2002:55e5:dbb7:0:1938:1947:dd20:55f0)
55. # [00:27] <smaug____> s/would//
56. # [00:27] <zewt> the only thing needed are eg. Int16BEArray, etc
57. # [00:27] <TabAtkins> zewt: Ken?
58. # [00:27] <jgraham> zewt: Sure. I was thinking of an abstract example
59. # [00:27] <aklein> smaug____: I don't care too much either, but I think we'd have to change our code too
60. # [00:28] <sicking> aklein: it seems to me that if someone observes the "value" attribute, and a page modifies the "xlink:value" attribute and we notify the observer, it seems unlikely that the observer would check that it's the "correct" value attribute that is changed and just assume that any notifications is to the attribute that it cares about
61. # [00:28] <zewt> one thing I need to recommend is that Int16LEArray (and friends) be added, so people can at least sidestep the issue
62. # [00:28] <jgraham> My point was just that saying "but there is a way to get this right" has never been good enough
63. # [00:28] <TabAtkins> zewt: I don't know how you'd use a normal view to access data from a BE file format with varying-width records.
64. # [00:28] <zewt> but kenneth has dug in his heels on this so far he seems unwilling to do anything at all
65. # [00:28] <jgraham> There is a way to generate well-formed XML, but that didn't happen either
66. # [00:29] <zewt> TabAtkins: views are used for arrays (fixed-width); variable-width (eg. structs) *is* what DataView is good for
67. # [00:29] <TabAtkins> zewt: I now understand his reasoning a bit better. It seems correct that trying to do LE everywhere would just mean "BE devices get *really slow* WebGL".
68. # [00:29] <zewt> TabAtkins: that's the only possible thing that can happen
69. # [00:29] <zewt> the alternative is "big-endian devices get broken WebGL"
70. # [00:29] <jgraham> TabAtkins: Instead they will get broken WebGL
71. # [00:29] <TabAtkins> Rather than the current one, which is "BE devices break when you're reading data that you assumed was LE".
72. # [00:29] <zewt> that's not correct; that's wrong
73. # [00:30] <TabAtkins> I've been told that, right now, BE devices work just fine in WebGL with typed arrays.
74. # [00:30] <zewt> you *should* be able to assume everything is little-endian. because nobody is, and nobody should have to, test on obscure big-endian devices; this is web 101--interoperability
75. # [00:30] <TabAtkins> They fail when you pull binary data off the network without using a dataview.
76. # [00:30] <zewt> which is broken
77. # [00:30] <sicking> aklein, smaug____: It seems to me that only observing the null-namespace is less bug-prone, and at least in the gecko implementation simpler since we wouldn't have a attributeNamespace property on MutationRecord
78. # [00:30] <zewt> you should never have to care about the endianness of the system you're on; it should have no visible effects on code, ever; and you should definitely not have to test on it
79. # [00:31] <aklein> sicking: now I'm a bit confused, are you saying attributeFilter won't stop the observer from telling me about _all_ namespaced attributes?
80. # [00:31] <zewt> it doesn't matter that fixing it makes big-endian systems slow--and who cares? nobody's making big-endian platforms anymore
81. # [00:31] <smaug____> sicking: it wouldn't change the record
82. # [00:31] * Joins: karlcow (~karl@nerval.la-grange.net)
83. # [00:31] <smaug____> sicking: only about filtering
84. # [00:31] <jgraham> TabAtkins: I am 100% sure that wih the current setup BE devices will be broken on most real sites that depend on binary data
85. # [00:31] * Parts: rarar3 (~subway@ridezap.com)
86. # [00:31] <smaug____> sicking: record must have the namespace
87. # [00:31] <sicking> smaug____: how so?
88. # [00:31] <TabAtkins> zewt: Shrug. From what I've heard, making the LE-everywhere assumption means that the common WebGL/WebAudio/other APIs that both generate and consume data in-page will be unacceptably slow on BE devices.
89. # [00:31] <smaug____> because you need to know which attribute changed
90. # [00:32] <TabAtkins> They're "work", but that's irrelevant.
91. # [00:32] <sicking> smaug____: oh, for when you are observing all attribute changes?
92. # [00:32] <TabAtkins> *They'll
93. # [00:32] <zewt> what BE devices?
94. # [00:32] <smaug____> sicking: yes
95. # [00:32] <jgraham> TabAtkins: I would like some proof of that with actual hardware
96. # [00:32] <TabAtkins> zewt: Aren't you assuming that BE devices exist and are important?
97. # [00:32] <TabAtkins> jgraham: Ask Ken. He alluded to years of experience with Java's NIO.
98. # [00:33] <sicking> aklein: sorry, yeah, so it wouldn't simplify the implementation a lot, but it seems less bugprone when attribute filters are used
99. # [00:33] <jgraham> Then I would like someone that actually ships in those devices to say taht they would prefer the site to not work than to be slow
100. # [00:33] <jgraham> s/in/on/
101. # [00:33] <zewt> no, I want this fixed so other APIs (eg. encoding API) don't keep getting derailed with "well we can't return UTF-16LE as Int16Array because it's native endian!" nonsense
102. # [00:33] * Quits: pyrsmk (~pyrsmk@mau49-1-82-245-46-173.fbx.proxad.net) (Quit: tzing)
103. # [00:33] <TabAtkins> jgraham: "Slow", past a certain point, is a synonym for "doesn't work".
104. # [00:33] <aklein> sicking: I assume this discussion is happening on a review, can you send the link?
105. # [00:33] <TabAtkins> jgraham: You wouldn't play a videogame running at 3fps. ^_^
106. # [00:34] <zewt> also, because it's a major, infrastructural API, and shouldn't have serious fundamental errors in the spec that everyone has to wink and ignore
107. # [00:34] <jgraham> TabAtkins: Do you have any data to say we are remotely at that point?
108. # [00:34] <sicking> aklein: still reviewing, but when i submit the review it'll appear here: https://bugzilla.mozilla.org/show_bug.cgi?id=641821
109. # [00:34] <TabAtkins> jgraham: Ken asserts that we are. I have no further data than that.
110. # [00:34] <jgraham> That's not useful
111. # [00:34] <TabAtkins> jgraham: Sorry. He provided some limited assertions in his recent emails. If you want more detail, respond there.
112. # [00:34] * Joins: nessy (~Adium@216.239.45.18)
113. # [00:34] <jgraham> (someone who has already made up their mind backing up their position with an assertion but no data)
114. # [00:35] <aklein> sicking: ah, ok, was hoping you'd laid out your suggestion there. what I'm wondering is, if I observe with attributeFilter == ['foo'], will I hear about changes to someNamespace:bar? or will I not hear about any namespaced attributes if I have an attributeFilter?
115. # [00:35] <smaug____> (aklein: sicking is shouting comments about the patch and API from the other side of the table)
116. # [00:36] <TabAtkins> zewt: From what I understand, we're screwed anyway. If it's not native-endian, performance-critical stuff like WebGL won't work. If it is native-endian, naive use of the API will break on unexpected endianness.
117. # [00:36] <jgraham> (and "doesn't work" is always a synonym for "doesn't work". The only way the curent situation could end well is if BE devices became so common that people had to test on both. I would bet on the opposite)
118. # [00:36] <TabAtkins> Luckily, the "worst case" that's been talked about (the author having to test and manually reorder bytes) doesn't exist once you have DataView.
119. # [00:36] <sicking> aklein: sorry, i don't remember enough of the spec. If you observer with attributeFilter == ['foo'], would you hear about changes to bar (in null namespace)?
120. # [00:36] <jgraham> Which authors won't use...
121. # [00:36] <TabAtkins> DataView still isn't maximally convenient, but it doesn't seem hard to come up with usability improvements.
122. # [00:36] <zewt> TabAtkins: web-compat trumps performance
123. # [00:36] <aklein> sicking: no
124. # [00:37] * jgraham -> sleep
125. # [00:37] <TabAtkins> zewt: Make up a new LE-only binary data that you can use for non-performance-critical stuff, then.
126. # [00:37] * Joins: schnoomac (~schnoomac@melbourne.99cluster.com)
127. # [00:37] <sicking> aklein: ok. Then no. I don't think you should hear about someNamespace:bar, nor someNamespace:foo either
128. # [00:37] <zewt> especially since the performance thing is meaningless (what BE platforms are there that this is actually optimizing for?)
129. # [00:37] <smaug____> aklein: so the if you have filter you wouldn't get records about any namespaced attribute changes
130. # [00:37] <sicking> aklein: i.e. there would be an implicit "null:" on everything in the filter
131. # [00:37] <zewt> TabAtkins: ... sorry, what?
132. # [00:38] <TabAtkins> zewt: I'm confused. You are questioning whether there are any BE platforms worth optimizing for. But then you complain that other APIs will break on BE platforms.
133. # [00:38] <TabAtkins> Do you care about BE platforms or not?
134. # [00:38] <sicking> aklein: namespaced attributes are used extremely rarely. It's only used in SVG and XBL1 as far as I know
135. # [00:38] <TabAtkins> sicking: And SVG is dropping them in SVG2.
136. # [00:38] <aklein> sicking: yeah, I'd be fine with this for that reason
137. # [00:38] <sicking> TabAtkins: woohoo!!!!
138. # [00:38] <aklein> seems like DOM4 is trying to deprecate them too
139. # [00:38] <TabAtkins> Fucking XLink.
140. # [00:38] <zewt> i've never claimed to care about BE platforms, but the argument that we need a broken spec that nobody would ever implement (if there ever were any) in order to optimize for those systems is just nonsense
141. # [00:38] <aklein> (at least by deemphasizing them in the spec text)
142. # [00:38] <smaug____> aklein: how is DOM4 trying to deprecate them?
143. # [00:39] <TabAtkins> zewt: I'm still confused, though. Your *vehement* objection to the current spec seems to be predicated on things breaking in BE platforms.
144. # [00:39] <aklein> smaug____: sorry, not "deprecate" so much as emphasizing the null namespace case
145. # [00:39] <shepazu> sicking: doesn't RDFa use namespaced attributes?
146. # [00:39] * Joins: sedovsek (~robert@93-103-90-17.dynamic.t-2.net)
147. # [00:39] <TabAtkins> But then you dismiss arguments about performance on BE platforms.
148. # [00:39] <sicking> shepazu: please god no!
149. # [00:39] <TabAtkins> shepazu: No.
150. # [00:39] <shepazu> it did at one point, I thought...
151. # [00:39] * gsnedders cares about web-compat and perf. on BE platforms
152. # [00:39] <zewt> TabAtkins: my objection is that the spec is unimplementable, and doesn't reflect reality
153. # [00:39] <aklein> smaug____: but this is why I don't care much about dropping them: I never use 'em
154. # [00:40] <smaug____> :)
155. # [00:40] <gsnedders> However, I don't think there's a solution that solves both.
156. # [00:40] <zewt> (unimplementable due to web compat, that is)
157. # [00:40] <TabAtkins> zewt: Your charge of "unimplementable" is based on BE platforms having problems with it due to breakage.
158. # [00:40] <TabAtkins> So once again, do you care about BE platforms or not?
159. # [00:40] <smaug____> aklein: sicking: I'll file a spec bug
160. # [00:40] <zewt> why are you asking me questions that I just answered?
161. # [00:40] <TabAtkins> Because you'r enot answering them.
162. # [00:40] <zewt> i type fast enough already; I don't need practice
163. # [00:40] <sicking> smaug____: awesome, thanks!
164. # [00:41] * heycam|away is now known as heycam
165. # [00:41] <TabAtkins> gsnedders: That's my fear.
166. # [00:41] <TabAtkins> gsnedders: If Ken can be proved wrong regarding the perf concerns, great. But he is experience in this, so I'm inclined to trust him. But I'm also clueless about this, so shrug.
167. # [00:41] <gsnedders> TabAtkins: I'd rather go for web-compat and slow than no web-compat and fast in the short term.
168. # [00:42] <shepazu> which devices are BE? ARM-based, or what?
169. # [00:42] <gsnedders> I don't know what the relative bottle-necks are with this stuff. Depends on what you're using them for.
170. # [00:42] <TabAtkins> zewt: You keep dismissing the "native endianness is needed for perf" by saying "who cares about perf on BE platforms?". But then you argue against native-endianness by saying that it breaks on BE platforms.
171. # [00:42] <gsnedders> shepazu: ARM is almost entirely LE now. Some MIPS stuff is.
172. # [00:42] <TabAtkins> shepazu: Yes, ARM is the major one.
173. # [00:42] <gsnedders> TabAtkins: What major ARM device is BE?
174. # [00:42] <gsnedders> (That can run a web browser)
175. # [00:42] <TabAtkins> gsnedders: Maybe, but like I said, past a certain point "slow" means "broken" for things like games.
176. # [00:43] <TabAtkins> gsnedders: I have no clue. I thought I'd been told that ARM is BE.
177. # [00:43] <gsnedders> Android, iOS, Sybmian, Windows Phone… they all use LE mode.
178. # [00:43] <zewt> TabAtkins: specs that are interoperable and don't expose platform obscurities is much more important than performance on obscure platforms
179. # [00:43] * Quits: KillerX (~anant@93.158.40.47) (Quit: KillerX)
180. # [00:43] <gsnedders> TabAtkins: Many RISC CPUs, ARM inc., are bi-endian.
181. # [00:43] <gsnedders> Most bi-endian CPUs nowadays are used in LE mode.
182. # [00:43] <zewt> gsnedders: qualify: "run a modern web browser" (eg. with WebGL, ArrayBuffers, the rest)
183. # [00:43] <gsnedders> zewt: Pretty much that dfn
184. # [00:44] <TabAtkins> zewt: Once again, that doesn't answer my question. Bad perf, in certain contexts, is equivalent to "broken". So you're saying that it's bad that the API is broken in BE platforms under some circumstances, but it doesn't matter that it's broken in BE platforms under other circumstances.
185. # [00:45] <zewt> you can always get bad performance; you can't make that go away (you can always write WebGL apps that tax the GPU so that it's only practically usable on a desktop); so no, I don't consider slow as equivalent to broken
186. # [00:45] <gsnedders> TabAtkins: Bad perf in certain contexts or broken in most contexts is the option here.
187. # [00:45] <TabAtkins> Your argument is thus inconsistent. You could instead be arguing that you think perf is an irrelevant circumstance, but you haven't made that argument so far.
188. # [00:45] <zewt> you're the only one claiming that slow == broken
189. # [00:46] <TabAtkins> zewt: For games, it is. Do you challenge that assertion?
190. # [00:46] <TabAtkins> For a game designed for 30fps, you can't reasonably play it at 3fps.
191. # [00:46] <TabAtkins> It's functionally equivalent to the game throwing an error immediately, for all the good it does you.
192. # [00:47] <gsnedders> TabAtkins: Most BE hardware with modern web browsers, even if content was delivered in BE form with native arrays, couldn't really push a 30fps game.
193. # [00:47] * Quits: jsbell (jsbell@nat/google/x-vnnfsgahtkcpbdps) (Read error: Operation timed out)
194. # [00:47] <zewt> so you're saying WebGL is broken because it's possible to write a game that requires the fill rate of a $500 Geforce, and runs at .1FPS on a phone?
195. # [00:47] <zewt> the game doesn't work, but that's not a bug in the spec or the API
196. # [00:48] <zewt> likewise, if byte swapping makes your app too slow to run, that's unfortunate but not a bug
197. # [00:48] <TabAtkins> zewt: Strawman. It's definitely possible to design a game optimized for phone-level hardware. The perf drop is then significant.
198. # [00:48] <TabAtkins> I'm unsure why you think "too slow to run" isn't a problem.
199. # [00:49] <zewt> it's not at all equivalent to the API being broken, which the spec currently is
200. # [00:49] <gsnedders> TabAtkins: Somehow we need a solution that allows interop in all cases, even with bad perf if you use the wrong API on the wrong hardware.
201. # [00:49] <TabAtkins> ...it's exactly the same. You use the API, it runs fine on your platform, but it's unusable on other platforms.
202. # [00:49] <gsnedders> That's my opinion, on the whole.
203. # [00:49] <TabAtkins> That's equivalent to using the API and it erroring out on other platforms.
204. # [00:49] <zewt> i'm also a bit appalled that anyone with any web experience is actually seriously arguing that it's okay to force web developers to care about endianness
205. # [00:49] <gsnedders> However, I think the shit has mostly sailed.
206. # [00:49] * Joins: danbri (~danbri@78.25.238.148)
207. # [00:50] <gsnedders> So practically we might be unable to do little more than spec stuff as LE
208. # [00:50] <Hixie> any web intents people around?
209. # [00:50] <TabAtkins> gsnedders: I'm normally with you, but bad perf is *really* killer for gaming, which is a case I'd like to strongly support. So I'd prefer something that doesn't have bad perf, and is easy to use in a compat way.
210. # [00:51] * Quits: sedovsek (~robert@93-103-90-17.dynamic.t-2.net) (Quit: sedovsek)
211. # [00:51] <gsnedders> TabAtkins: What I'm basically suggesting there is always a way to get native perf on a certain endianness, but there may be more ways to get bad, byte-swapping perf on it too, though the behaviour will always be consistent.
212. # [00:51] * Joins: jsbell (jsbell@nat/google/x-qxkknwndgfzuqmiy)
213. # [00:52] <TabAtkins> Maybe.
214. # [00:52] <TabAtkins> I wonder if we can do something like make XHR return a DataView for "arraybuffer"?
215. # [00:52] <TabAtkins> Probably not, now.
216. # [00:52] * Joins: sedovsek (~robert@93-103-90-17.dynamic.t-2.net)
217. # [00:53] <gsnedders> A Uint8DataView makes the most sense, IMO
218. # [00:53] <zewt> ouch, that's the most confusing name imaginable :P
219. # [00:54] <TabAtkins> A DataView with UInt8 array-like behavior?
220. # [00:54] <gsnedders> Better than ClampedUint8DataView
221. # [00:54] <gsnedders> Oh, no, I'm thinking of the arrays again.
222. # [00:54] <gsnedders> Duh.
223. # [00:54] <gsnedders> For some reason I always think they're data views.
224. # [00:54] <roc> TabAtkins, annevk: "They can't realistically search your entire set of OS fonts when attempting to render a page." ... well, that's exactly what Firefox does
225. # [00:55] <roc> if necessary
226. # [00:55] * TabAtkins liked the ES record stuff that progressed too slowly and got preempted by this, because it could have let you describe the fields of your data so you get automatic byte-swapping.
227. # [00:55] <TabAtkins> roc: I didn't know that!
228. # [00:55] <TabAtkins> I assumed you had a normal font-stack with Last Resort at the end.
229. # [00:56] * Quits: drublic (~drublic@frbg-5f7310bf.pool.mediaWays.net) (Remote host closed the connection)
230. # [00:59] * hober2 is now known as hober
231. # [01:05] * Joins: dinesh_ (~dinesh@fr1-dinesh.box.dinsoft.org)
232. # [01:06] * Quits: dinesh___ (~dinesh@fr1-dinesh.box.dinsoft.org) (Ping timeout: 264 seconds)
233. # [01:09] * Joins: drublic (~drublic@frbg-5f7310bf.pool.mediaWays.net)
234. # [01:11] * Quits: sedovsek (~robert@93-103-90-17.dynamic.t-2.net) (Quit: sedovsek)
235. # [01:12] * Quits: danbri (~danbri@78.25.238.148) (Remote host closed the connection)
236. # [01:12] <TabAtkins> So what's this "LE mode" I'm hearing about? And what's its relevance to the discussion?
237. # [01:13] * Joins: Lachy (~Lachy@cm-84.215.13.244.getinternet.no)
238. # [01:13] <roc> I discovered yesterday that ARM CPUs can switch endianness on the fly with a single instruction
239. # [01:14] <Hixie> wow
240. # [01:14] <Hixie> that's hardcore
241. # [01:14] <zewt> how does that actually work? i'd think changing the endianness of your pointers would do ... bad stuff
242. # [01:14] <zewt> only affects math, maybe?
243. # [01:14] <roc> "carefully"
244. # [01:14] <zewt> heh
245. # [01:14] <zewt> "wear a helmet"
246. # [01:14] <roc> I assumed it affects all loads and stores
247. # [01:15] * Quits: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com) (Quit: Leaving...)
248. # [01:15] <zewt> is the opcode MSHRMCLD?
249. # [01:15] <roc> http://www.doulos.com/knowhow/arm/Hints_and_Tips/Byte_Swapping/
250. # [01:15] <TabAtkins> Oh, wow: "Oops! Google Chrome could not connect to hint.fm
251. # [01:15] <TabAtkins> Other users are also experiencing difficulties connecting to this site, so you may have to wait a few minutes."
252. # [01:15] <TabAtkins> That's pretty cool. <3 anonymous usage data.
253. # [01:16] <TabAtkins> roc: I suppose that wouldn't help the GPU, though?
254. # [01:16] <roc> There is a way to make the Web safe for BE machines. Have Chrome randomly emulate BE 10% of the time.
255. # [01:16] <Hixie> i've proposed that kind of thing in the past
256. # [01:16] <zewt> what about big-endian systems with little-endian GPUs?
257. # [01:16] <zewt> (sorry, I had to say it)
258. # [01:17] <roc> TabAtkins: yeah, I think what actually matters here is BE *GPUs*
259. # [01:17] <Hixie> e.g. my websocket design required the ua to randomise the order of headers in the handshake
260. # [01:17] <TabAtkins> I keep proposing stochastic prefix inclusion. It hasn't yet made it past the laugh test.
261. # [01:17] <zewt> Hixie: that sounds challenging to test, heh
262. # [01:17] <TabAtkins> But I feel like it's kinda close.
263. # [01:17] <zewt> (a bit unreasonable to expect of servers, though)
264. # [01:17] <TabAtkins> (That is, only release prefixed things to the release channel in X% of browsers.)
265. # [01:18] <zewt> (er, clients, I guess)
266. # [01:18] <zewt> seems sort of questionable to expect people to introduce complexity (and therefore bugs) in order to reduce bugs
267. # [01:18] <TabAtkins> That's pretty much been the argument against it, yeah.
268. # [01:18] <TabAtkins> But randomness is so useful!
269. # [01:18] <TabAtkins> So many things can be solved easier with randomness than with a deterministic process.
270. # [01:19] <zewt> especially since it's expecting people to introduce bugs in *their* stuff, to reduce bugs in someone else's
271. # [01:21] <roc> It seems to me that WebGL performance issues on BE machines could be solved in the driver.
272. # [01:23] <TabAtkins> No clue.
273. # [01:24] <TabAtkins> roc: Btw, if you're still interested in measurement APIs and such (improvements in the vein of getBoundingClientRect, etc.), we're gaining someone who wants to do spec/impl work and is interested in this.
274. # [01:25] * Joins: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com)
275. # [01:25] * Quits: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Ping timeout: 265 seconds)
276. # [01:26] * Joins: danbri (~danbri@78.25.238.148)
277. # [01:27] * Quits: drublic (~drublic@frbg-5f7310bf.pool.mediaWays.net) (Remote host closed the connection)
278. # [01:27] * Quits: danbri (~danbri@78.25.238.148) (Remote host closed the connection)
279. # [01:32] <Philip`> ARMv7 apparently always reads instructions as little-endian (except for a legacy mode in the "real-time" profile which can optionally be hardwired to do big-endian); otherwise the endianness just affects all load/store instructions (including NEON ones) (not registers or arithmetic or anything)
280. # [01:32] <TabAtkins> Looking at DataView in practice, I see why it's not expected to be used. http://code.google.com/p/webglsamples/source/browse/hdr/hdr.js#235
281. # [01:32] <TabAtkins> Sheesh.
282. # [01:33] <TabAtkins> You need to take an array buffer, wrap it in a data view, iterate over it with some moderately long boilerplate, and copy it into another array buffer.
283. # [01:33] <TabAtkins> This could be made *enormously* more convenient to use.
284. # [01:35] <Philip`> (I don't see anything saying SETEND can only be used from privileged modes, so maybe it can actually be used arbitrarily by applications?)
285. # [01:36] * Quits: tantek (~tantek@c-76-115-51-221.hsd1.or.comcast.net) (Quit: tantek)
286. # [01:37] <TabAtkins> Hixie: If you didn't see it, lunch next week on tuesday.
287. # [01:38] <Hixie> TabAtkins: awesome. at goog?
288. # [01:38] <TabAtkins> Yeah.
289. # [01:38] <TabAtkins> Hopefully with tantek too.
290. # [01:38] <Hixie> any idea what time?
291. # [01:38] <TabAtkins> Let me check scrollback...
292. # [01:39] <TabAtkins> noon
293. # [01:39] <Hixie> k
294. # [01:40] <Hixie> added to calendar
295. # [01:40] <Hixie> do we have a meeting place planned?
296. # [01:42] <TabAtkins> not yet
297. # [01:42] <Hixie> k
298. # [01:42] <Hixie> ok, i'm outta here. i'll be at San Jose's FRC regional the next three days. back monday.
299. # [01:47] * Joins: danbri (~danbri@78.25.238.148)
300. # [01:49] * Quits: danbri (~danbri@78.25.238.148) (Remote host closed the connection)
301. # [01:53] <roc> zewt: what do you mean, "Benoit's email"?
302. # [01:56] <roc> hmm, I'm missing email
303. # [01:59] <zewt> roc: "FWIW, here is a way to do this that will always work and won't rely on "luck". The key idea is that by the time one draws stuff, all the information about how vertex attributes use buffer data must be known. ..."
304. # [01:59] <roc> I found it in the archives
305. # [02:02] <zewt> uh, wait, what the
306. # [02:02] <zewt> kenneth is actually talking about polymorphism dispatch overhead in Java as if it has any relevance to JS?
307. # [02:03] <TabAtkins> The implication, I assume, is that similar JITing concerns may apply.
308. # [02:03] * Philip` supposes the most irritating case is if you have overlaps like "char data[] = { 0x01, 0x02, 0x03 }; glVertexAttribPointer(a, 1, GL_SHORT, 0, 0, data); glVertexAttribPointer(b, 1, GL_SHORT, 0, 0, data+1);", which should give one value 0x0102 and one 0x0203
309. # [02:04] <zewt> but there's really no parallel, i think, between the way JS and Java dispatch works and optimizes
310. # [02:04] <TabAtkins> Philip`: Ooh, that's true.
311. # [02:04] <Philip`> (so you'd have to expand into non-overlapping arrays if you wanted to swap bytes)
312. # [02:04] <zewt> Philip`: is "shoot the programmer in the head" an acceptable answer?
313. # [02:04] <TabAtkins> Damn, if you pack that way you can't early-swap at all.
314. # [02:04] * Joins: xbuzz (~chris@c-71-232-28-255.hsd1.ma.comcast.net)
315. # [02:05] <Philip`> zewt: I don't think it's explicitly undefined behaviour, so shooting the programmer is unlikely to be permitted, especially since it will violate the invariance requirements
316. # [02:05] <zewt> Philip`: it violates the "you really, seriously need to be shot in the head" requirement
317. # [02:06] * Joins: jacobolus (~jacobolus@75-144-246-6-SFBA.hfc.comcastbusiness.net)
318. # [02:06] <zewt> if WebGL was designed sanely, it just wouldn't allow that--but they're obsessed with trying to make WebGL just like OpenGL (a serious design mistake, if you ask me)
319. # [02:06] * Joins: danbri (~danbri@78.25.238.138)
320. # [02:06] <zewt> (making it an overlay of it, so they don't have to actually define it all, is good, of course)
321. # [02:06] * Quits: smaug____ (~chatzilla@12.197.88.252) (Remote host closed the connection)
322. # [02:07] * Quits: jsbell (jsbell@nat/google/x-qxkknwndgfzuqmiy) (Quit: There's no place like home...)
323. # [02:08] <roc> I don't see that the JITTing concerns apply
324. # [02:08] <roc> if you're on a big-endian machine, an Int32Array would always byteswap. That's it.
325. # [02:09] <Philip`> Has anyone suggested/objected to doing something like defining a GL_OES_vertex_array_endianness extension so browsers can tell drivers to deal with the problem themselves, and then only support big-endian devices that provide that extension?
326. # [02:09] <roc> yes, I just suggested that
327. # [02:09] <zewt> this is what I'm referring to:
328. # [02:09] <zewt> The result was increased polymorphism at call sites, which defeated the Java VM's optimizing compiler and led to 10x slowdowns in many common situations.
329. # [02:09] <zewt> which seems 100% irrelevant to JS
330. # [02:09] <roc> in reality I bet you could easily extend the GPU to run in little-endian mode, since obviously every GPU part is going to support little-endian so it works with 99% of the CPUs out there
331. # [02:10] * Joins: smaug____ (~chatzilla@12.197.88.252)
332. # [02:12] <zewt> ... assuming they can even run in big-endian to begin with
333. # [02:13] <zewt> i'd find it pretty sadly amusing if a big-endian system did crop up, and WebGL didn't work on it because its GPU was little-endian, and everything would have worked otherwise
334. # [02:21] * Quits: ap (~ap@17.212.155.203) (Quit: ap)
335. # [02:25] * Quits: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com) (Quit: Leaving...)
336. # [02:37] * Quits: chriseppstein (~chrisepps@209.119.65.162) (Quit: chriseppstein)
337. # [02:38] * Quits: danbri (~danbri@78.25.238.138) (Ping timeout: 245 seconds)
338. # [02:47] * Quits: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90) (Quit: ChatZilla 0.9.87-4.1450hg.fc15 [XULRunner 10.0.1/20120216115618])
339. # [02:49] * Joins: ehsan (~ehsan@12.197.88.252)
340. # [02:51] * Quits: Druid_ (~Druid@p5B05D968.dip.t-dialin.net) (Ping timeout: 265 seconds)
341. # [02:52] * Quits: necolas (~necolas@5ade4db9.bb.sky.com) (Ping timeout: 245 seconds)
342. # [02:55] * Joins: Druid_ (~Druid@p5B1357B7.dip.t-dialin.net)
343. # [02:58] * Joins: necolas (~necolas@5e0c2226.bb.sky.com)
344. # [03:01] * Joins: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com)
345. # [03:02] * Quits: jamesr (jamesr@nat/google/x-dpozpvmxyrrqfcjf) (Quit: jamesr)
346. # [03:03] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
347. # [03:12] * Quits: jdaggett (~jdaggett@12.197.88.252) (Quit: jdaggett)
348. # [03:13] * Quits: dinesh_ (~dinesh@fr1-dinesh.box.dinsoft.org) (Ping timeout: 244 seconds)
349. # [03:14] * Quits: ehsan (~ehsan@12.197.88.252) (Remote host closed the connection)
350. # [03:14] * Joins: dinesh___ (~dinesh@fr1-dinesh.box.dinsoft.org)
351. # [03:18] * Joins: dinesh_ (~dinesh@fr1-dinesh.box.dinsoft.org)
352. # [03:18] * Quits: dinesh___ (~dinesh@fr1-dinesh.box.dinsoft.org) (Ping timeout: 252 seconds)
353. # [03:18] * Quits: pablof (~pablof@144.189.101.1) (Quit: ^z)
354. # [03:23] * Joins: mkanat (~mkanat@216.239.45.130)
355. # [03:28] * jonlee is now known as jonlee|afk
356. # [03:28] * Quits: necolas (~necolas@5e0c2226.bb.sky.com) (Ping timeout: 260 seconds)
357. # [03:33] <roc> there are big-endian systems with GPUs so it's doable somehow or other
358. # [03:34] * jonlee|afk is now known as jonlee
359. # [03:40] * Quits: dbaron (~dbaron@12.197.88.252) (Ping timeout: 244 seconds)
360. # [03:40] * Quits: aklein (u4454@gateway/web/irccloud.com/x-rzsrlrtzljqfxavi)
361. # [03:40] * Quits: sicking (~chatzilla@12.197.88.252) (Ping timeout: 260 seconds)
362. # [03:41] * Quits: smaug____ (~chatzilla@12.197.88.252) (Ping timeout: 265 seconds)
363. # [03:50] * Quits: jacobolus (~jacobolus@75-144-246-6-SFBA.hfc.comcastbusiness.net) (Read error: Connection reset by peer)
364. # [03:50] * Joins: jryans (~jryans@cpe-70-124-81-135.austin.res.rr.com)
365. # [03:52] * Joins: karega (karega@cpe-76-184-236-100.tx.res.rr.com)
366. # [03:52] * jonlee is now known as jonlee|afk
367. # [03:53] * Joins: jacobolus (~jacobolus@75-144-246-6-SFBA.hfc.comcastbusiness.net)
368. # [03:57] * Joins: jacobolu_ (~jacobolus@75-144-246-6-SFBA.hfc.comcastbusiness.net)
369. # [03:57] * Joins: chriseppstein (~chrisepps@99-6-85-4.lightspeed.sntcca.sbcglobal.net)
370. # [03:59] * Quits: jacobolus (~jacobolus@75-144-246-6-SFBA.hfc.comcastbusiness.net) (Ping timeout: 272 seconds)
371. # [04:04] <zewt> i wonder if that's an actual big-endian GPU, if the drivers fake it, or something else
372. # [04:07] * Joins: scor (~scor@drupal.org/user/52142/view)
373. # [04:11] <mkanat> I missed the start of this conversation, is it about shaders?
374. # [04:14] * Quits: rniwa (rniwa@nat/google/x-qgowhpnpkltmfhkd) (Quit: rniwa)
375. # [04:16] * Quits: mkanat (~mkanat@216.239.45.130) (Ping timeout: 260 seconds)
376. # [04:22] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
377. # [04:46] * Joins: myakura (~myakura@FL1-110-233-178-43.tky.mesh.ad.jp)
378. # [04:47] * Quits: KevinMarks (~KevinMark@c-71-204-145-244.hsd1.ca.comcast.net) (Quit: The computer fell asleep)
379. # [04:50] * Quits: jacobolu_ (~jacobolus@75-144-246-6-SFBA.hfc.comcastbusiness.net) (Remote host closed the connection)
380. # [04:54] * Quits: nessy (~Adium@216.239.45.18) (Quit: Leaving.)
381. # [04:58] * Quits: Neocortex (~niels@82-170-160-25.ip.telfort.nl) (Ping timeout: 252 seconds)
382. # [05:00] <zewt> this is pretty fantastic
383. # [05:00] <zewt> my internet connection is corrupting IP packets in a way that checksums can't detect
384. # [05:01] <zewt> crcs please :|
385. # [05:02] * Quits: jryans (~jryans@cpe-70-124-81-135.austin.res.rr.com) (Quit: Leaving...)
386. # [05:24] * Joins: dinesh___ (~dinesh@fr1-dinesh.box.dinsoft.org)
387. # [05:26] * Quits: dinesh_ (~dinesh@fr1-dinesh.box.dinsoft.org) (Ping timeout: 265 seconds)
388. # [05:27] * Joins: hij1nx (~hij1nx@cpe-66-65-173-74.nyc.res.rr.com)
389. # [05:27] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
390. # [05:35] * Quits: hij1nx (~hij1nx@cpe-66-65-173-74.nyc.res.rr.com) (Quit: hij1nx)
391. # [05:41] * Joins: hij1nx (~hij1nx@cpe-66-65-173-74.nyc.res.rr.com)
392. # [05:44] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
393. # [05:47] * Quits: hij1nx (~hij1nx@cpe-66-65-173-74.nyc.res.rr.com) (Quit: hij1nx)
394. # [05:52] * Quits: twisted` (~twisted@p5DDB9DC3.dip.t-dialin.net) (Quit: Computer has gone to sleep.)
395. # [05:56] * Quits: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
396. # [05:57] * Joins: hij1nx (~hij1nx@cpe-66-65-173-74.nyc.res.rr.com)
397. # [06:04] * Joins: dydx (~dydz@adsl-76-199-101-60.dsl.pltn13.sbcglobal.net)
398. # [06:12] * Quits: schnoomac (~schnoomac@melbourne.99cluster.com) (Quit: schnoomac)
399. # [06:12] * Joins: schnoomac (~schnoomac@melbourne.99cluster.com)
400. # [06:16] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
401. # [06:24] * Quits: hij1nx (~hij1nx@cpe-66-65-173-74.nyc.res.rr.com) (Quit: hij1nx)
402. # [06:26] * Joins: smaug____ (~chatzilla@12.197.88.10)
403. # [06:33] * Joins: izhak (~izhak@213.87.241.66)
404. # [06:36] * jonlee|afk is now known as jonlee
405. # [06:36] * Quits: xbuzz (~chris@c-71-232-28-255.hsd1.ma.comcast.net) (Quit: xbuzz)
406. # [06:40] * Quits: cpearce (~cpearce@60.234.54.74) (Ping timeout: 260 seconds)
407. # [06:41] * Joins: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com)
408. # [06:48] * Joins: niloy (~niloy@61.12.96.242)
409. # [06:57] * Joins: dbaron (~dbaron@173-228-85-36.dsl.dynamic.sonic.net)
410. # [07:03] * Joins: ehsan (~ehsan@12.197.88.10)
411. # [07:05] * Quits: espadrine (~thaddee_t@acces2373.res.insa-lyon.fr) (Quit: espadrine)
412. # [07:06] * Joins: KillerX (~anant@93.158.40.132)
413. # [07:06] * Quits: mbatle (mbatle@pasanda.collabora.co.uk) (Ping timeout: 245 seconds)
414. # [07:10] * Joins: jryans (~jryans@cpe-70-124-81-135.austin.res.rr.com)
415. # [07:15] * Joins: jdaggett (~jdaggett@12.197.88.10)
416. # [07:15] * Quits: jdaggett (~jdaggett@12.197.88.10) (Client Quit)
417. # [07:16] * Joins: Areks (~Areks@rs.gridnine.com)
418. # [07:27] * Joins: mbatle (~mbatle@pasanda.collabora.co.uk)
419. # [07:40] * Quits: JohnAlbin (~JohnAlbin@114-42-63-53.dynamic.hinet.net) (Quit: HTTP/1.1 404 JohnAlbin Not Found)
420. # [07:41] * Joins: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se)
421. # [07:41] * Joins: JohnAlbin (~JohnAlbin@114-42-63-53.dynamic.hinet.net)
422. # [07:41] * Quits: roc (~chatzilla@60.234.54.74) (Ping timeout: 246 seconds)
423. # [07:43] * Joins: GlitchMr (~glitchmr@178-36-159-249.adsl.inetia.pl)
424. # [07:45] * Joins: Ducki (~Ducki@pD9E3935C.dip0.t-ipconnect.de)
425. # [07:46] * Joins: portenkirchner (~portenkir@p5DCD6699.dip.t-dialin.net)
426. # [07:48] * Quits: portenkirchner (~portenkir@p5DCD6699.dip.t-dialin.net) (Client Quit)
427. # [07:48] * Joins: portenkirchner (~portenkir@p5DCD6699.dip.t-dialin.net)
428. # [07:48] * Quits: portenkirchner (~portenkir@p5DCD6699.dip.t-dialin.net) (Client Quit)
429. # [07:59] * Quits: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com) (Quit: hij1nx)
430. # [08:06] * Quits: benjoffe (~benjoffe@119-252-71-224.static.highway1.net.au) (Remote host closed the connection)
431. # [08:13] * Joins: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de)
432. # [08:17] * Quits: KillerX (~anant@93.158.40.132) (Quit: KillerX)
433. # [08:21] * Joins: kaustubh (~kaustubh@144.187.36.11)
434. # [08:23] * Quits: smaug____ (~chatzilla@12.197.88.10) (Ping timeout: 244 seconds)
435. # [08:24] * Joins: tomasf_ (~tomasf@77.72.97.5.c.fiberdirekt.net)
436. # [08:30] * Quits: jryans (~jryans@cpe-70-124-81-135.austin.res.rr.com) (Quit: Leaving...)
437. # [08:31] * Joins: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net)
438. # [08:32] * Quits: dydx (~dydz@adsl-76-199-101-60.dsl.pltn13.sbcglobal.net) (Quit: dydx)
439. # [08:34] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Ping timeout: 260 seconds)
440. # [08:35] * Quits: jochen__ (jochen@nat/google/x-xkzmjrpoxtzltfxr) (Remote host closed the connection)
441. # [08:35] * Joins: jochen__ (jochen@nat/google/x-qmqwwcxrtddkhoso)
442. # [08:36] * Quits: schnoomac (~schnoomac@melbourne.99cluster.com) (Quit: schnoomac)
443. # [08:36] * Joins: PalleZingmark (~Adium@217.13.228.226)
444. # [08:37] <hsivonen> zcorpan: wow. that's surprising.
445. # [08:37] <hsivonen> zcorpan: jslint getting fixed ahead of jshint that is
446. # [08:37] * Parts: Sirisian (~Sirisian@adsl-69-208-90-211.dsl.klmzmi.ameritech.net) ("Leaving")
447. # [08:38] * Joins: tantek (~tantek@c-76-115-51-221.hsd1.or.comcast.net)
448. # [08:40] <zcorpan> yeah
449. # [08:40] * Joins: guanqun (Lu@nat/intel/x-vocggcttjldyazde)
450. # [08:42] * Joins: nessy (~Adium@209.118.182.194)
451. # [08:44] * Quits: Bass10 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Ping timeout: 244 seconds)
452. # [08:48] * Joins: LBP (~Mirc@pD9EB1505.dip0.t-ipconnect.de)
453. # [08:49] * Joins: dydx (~dydz@adsl-76-199-101-60.dsl.pltn13.sbcglobal.net)
454. # [08:54] * Quits: mven (~mven__@169.241.49.57) (Read error: Connection reset by peer)
455. # [08:55] * Joins: mven (~mven__@169.241.49.57)
456. # [08:58] * Quits: dbaron (~dbaron@173-228-85-36.dsl.dynamic.sonic.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
457. # [09:02] * Quits: chriseppstein (~chrisepps@99-6-85-4.lightspeed.sntcca.sbcglobal.net) (Quit: chriseppstein)
458. # [09:03] * JohnAlbin is now known as JohnAlbin_afk
459. # [09:06] <annevk> well well
460. # [09:06] <annevk> are we going to publish today
461. # [09:06] <annevk> or not
462. # [09:06] <annevk> my magic eight ball says unlikely
463. # [09:08] <annevk> html5 seems ready, but 2dcontext and html5-diff are not put into place, didn't bother checking more
464. # [09:15] * Joins: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net)
465. # [09:15] * Joins: roc (~chatzilla@121.98.230.221)
466. # [09:23] * Quits: Ducki (~Ducki@pD9E3935C.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
467. # [09:24] * Quits: dydx (~dydz@adsl-76-199-101-60.dsl.pltn13.sbcglobal.net) (Quit: dydx)
468. # [09:27] <MikeSmith> annevk: we will publish
469. # [09:27] <MikeSmith> I'll get the rest done later today my time
470. # [09:28] <annevk> goody
471. # [09:28] <annevk> slightly less obsolete drafts on TR/ :)
472. # [09:28] <MikeSmith> heh
473. # [09:29] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 244 seconds)
474. # [09:30] * Joins: Ducki (~Ducki@pD9E3935C.dip0.t-ipconnect.de)
475. # [09:33] * Joins: cpearce (~cpearce@ip-118-90-36-173.xdsl.xnet.co.nz)
476. # [09:33] * Quits: nessy (~Adium@209.118.182.194) (Quit: Leaving.)
477. # [09:33] * Joins: danbri (~danbri@78.25.238.133)
478. # [09:34] * Joins: Neocortex (~niels@82-170-160-25.ip.telfort.nl)
479. # [09:39] * Quits: tantek (~tantek@c-76-115-51-221.hsd1.or.comcast.net) (Quit: tantek)
480. # [09:39] * Joins: jernoble_ (~jernoble@2620:149:4:1b01:20d0:534b:97e6:88df)
481. # [09:39] * Joins: jonlee_ (~jonlee@2620:149:4:1b01:3d51:6f20:d693:eeaf)
482. # [09:39] * Joins: onar_ (~onar@17.216.36.168)
483. # [09:39] * Joins: eric_carlson (~eric@2620:149:4:1b01:20e0:60ba:94ff:ab03)
484. # [09:40] * Quits: onar (~onar@17.216.36.168) (Read error: Operation timed out)
485. # [09:40] * onar_ is now known as onar
486. # [09:40] * Quits: jernoble (~jernoble@2620:149:4:1b01:20d0:534b:97e6:88df) (Read error: Operation timed out)
487. # [09:40] * Quits: ericc|afk (~eric@2620:149:4:1b01:740e:9fff:de25:b37a) (Read error: Operation timed out)
488. # [09:40] * jernoble_ is now known as jernoble
489. # [09:41] * Quits: jonlee (~jonlee@2620:149:4:1b01:9d05:e3da:9d25:d6ed) (Ping timeout: 260 seconds)
490. # [09:41] * jonlee_ is now known as jonlee
491. # [09:43] * Quits: karega (karega@cpe-76-184-236-100.tx.res.rr.com) (Ping timeout: 245 seconds)
492. # [09:49] <annevk> I wonder if "Let row be the arithmetic left shift of lead − lead offset by 1 − adjust − 33" is better replaced by something like "Let row be ((lead - lead offset) << 1) - adjust - 33".
493. # [09:50] <annevk> in other words, how do I get away with using << in mathematical expressions in standards
494. # [09:51] <zcorpan> say what "<<" means in the terminology section
495. # [09:56] * jonlee is now known as jonlee|afk
496. # [09:56] * Quits: ehsan (~ehsan@12.197.88.10) (Remote host closed the connection)
497. # [09:56] <annevk> In mathematical expressions << means the arithmetic left shift of the left operand by the right operand.
498. # [09:56] <annevk> something like that?
499. # [09:57] <annevk> hmm
500. # [10:02] <annevk> in Unicode math has ≪ which stands for much less-than
501. # [10:02] <annevk> there's even ⋘
502. # [10:02] <annevk> :)
503. # [10:04] <annevk> oh well, I'll clarify it via some other way
504. # [10:06] <charlvn> only place i've ever used << and >> was in c++ http://www.cplusplus.com/doc/tutorial/basic_io/
505. # [10:08] <annevk> they're available in JavaScript
506. # [10:08] <charlvn> i think it's supposed to be used for left shifts and right shifts though http://wiki.python.org/moin/BitwiseOperators
507. # [10:09] <charlvn> heh! never expected that but it's also documented on mdn https://developer.mozilla.org/en/JavaScript/Reference/Operators/Bitwise_Operators
508. # [10:10] <charlvn> so few people use these, most people just use *2 and /2
509. # [10:10] <annevk> well yes, that's what I was going to use it for
510. # [10:11] <charlvn> is it really that much more efficient? i would expect the interpreter / compiler to perform such optimisations
511. # [10:12] <charlvn> in favour of readable code
512. # [10:12] * Quits: Ducki (~Ducki@pD9E3935C.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
513. # [10:13] <annevk> what is more readable depends on what you are doing
514. # [10:13] <annevk> the context here is encoding algorithms
515. # [10:13] <charlvn> that's very true
516. # [10:14] <charlvn> last year i got asked a ridiculous question during an internet with google ireland - how to count the number of binary 1's in an int32
517. # [10:14] <charlvn> that was the only time in my life i ever decided to use a shift and that was mostly for academical reasons
518. # [10:14] <charlvn> s/internet/interview/
519. # [10:15] * Quits: mpt (~mpt@canonical/mpt) (Read error: Connection reset by peer)
520. # [10:16] * heycam is now known as heycam|away
521. # [10:17] * Joins: Ducki (~Ducki@pD9E3935C.dip0.t-ipconnect.de)
522. # [10:18] * Joins: mpt (~mpt@nat/canonical/x-npseiosiyvjvwmbe)
523. # [10:18] * Quits: mpt (~mpt@nat/canonical/x-npseiosiyvjvwmbe) (Changing host)
524. # [10:18] * Joins: mpt (~mpt@canonical/mpt)
525. # [10:18] <annevk> charlvn: quick search on Google reveals it's not such a weird question: http://en.wikipedia.org/wiki/Hamming_weight
526. # [10:37] * Quits: karlcow (~karl@nerval.la-grange.net) (Remote host closed the connection)
527. # [10:39] * Joins: drublic (~drublic@frbg-4d029775.pool.mediaWays.net)
528. # [10:41] * Joins: Ms2ger (~Ms2ger@91.181.135.207)
529. # [10:44] * Joins: sedovsek (~robert@93-103-90-17.dynamic.t-2.net)
530. # [10:48] * Quits: sedovsek (~robert@93-103-90-17.dynamic.t-2.net) (Client Quit)
531. # [10:59] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 260 seconds)
532. # [10:59] * Joins: temp02 (~temp01@unaffiliated/temp01)
533. # [11:11] * Quits: macpherson (~macpherso@74.125.56.17) (Ping timeout: 240 seconds)
534. # [11:14] * Quits: danbri (~danbri@78.25.238.133) (Ping timeout: 260 seconds)
535. # [11:17] * Quits: myakura (~myakura@FL1-110-233-178-43.tky.mesh.ad.jp) (Remote host closed the connection)
536. # [11:18] * Joins: macpherson (~macpherso@2401:fa00::ea06:88ff:fecc:9412)
537. # [11:20] * Joins: mattwest (~mattwest@host81-149-171-23.in-addr.btopenworld.com)
538. # [11:21] * Joins: mattwest_ (~mattwest@host81-149-171-23.in-addr.btopenworld.com)
539. # [11:22] * Quits: mattwest (~mattwest@host81-149-171-23.in-addr.btopenworld.com) (Client Quit)
540. # [11:22] * mattwest_ is now known as mattwest
541. # [11:22] * Quits: Ducki (~Ducki@pD9E3935C.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
542. # [11:22] * Joins: Ducki (~Ducki@pD9E3935C.dip0.t-ipconnect.de)
543. # [11:24] * Parts: mattwest (~mattwest@host81-149-171-23.in-addr.btopenworld.com)
544. # [11:26] * Quits: dinesh___ (~dinesh@fr1-dinesh.box.dinsoft.org) (Read error: Connection reset by peer)
545. # [11:26] * Joins: dinesh___ (~dinesh@fr1-dinesh.box.dinsoft.org)
546. # [11:26] * Joins: mattwest (5195ab17@gateway/web/freenode/ip.81.149.171.23)
547. # [11:28] * Quits: mattwest (5195ab17@gateway/web/freenode/ip.81.149.171.23) (Client Quit)
548. # [11:29] * Joins: mattwest (~textual@host81-149-171-23.in-addr.btopenworld.com)
549. # [11:33] * Quits: Lachy (~Lachy@cm-84.215.13.244.getinternet.no) (Quit: Computer has gone to sleep.)
550. # [11:33] * Quits: mattwest (~textual@host81-149-171-23.in-addr.btopenworld.com) (Client Quit)
551. # [11:34] * Joins: mattwest (~textual@host81-149-171-23.in-addr.btopenworld.com)
552. # [11:37] <annevk> zcorpan: undefined
553. # [11:45] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Quit: rniwa)
554. # [11:45] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
555. # [11:46] * Joins: Lachy (Lachy@nat/opera/x-pzcnpaxcmjvicyyv)
556. # [11:51] <charlvn> annevk: it's a common question to ask in interviews, but it would be nice to see some practical use cases :P
557. # [11:53] <charlvn> http://en.wikipedia.org/wiki/Hamming_weight#Efficient_implementation <- this is what it's relevant for (in interviews, not use cases)
558. # [12:06] * Quits: cpearce (~cpearce@ip-118-90-36-173.xdsl.xnet.co.nz) (Ping timeout: 246 seconds)
559. # [12:11] * Joins: karlcow (~karl@nerval.la-grange.net)
560. # [12:16] * Joins: necolas (~necolas@176.251.237.207)
561. # [12:17] * Quits: charlvn (~charlvn@charlvn.nl) (Quit: leaving)
562. # [12:19] * Joins: charlvn (~charlvn@2002:8259:81f2::1)
563. # [12:23] * Quits: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Ping timeout: 272 seconds)
564. # [12:23] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
565. # [12:44] * Joins: karega (~karegaani@cpe-76-184-236-100.tx.res.rr.com)
566. # [12:54] <annevk> hsivonen: did you see https://bugs.webkit.org/show_bug.cgi?id=26694 ?
567. # [12:58] * Joins: nonge_ (~nonge@p5082B19C.dip.t-dialin.net)
568. # [13:02] * Quits: nonge (~nonge@p5082A74E.dip.t-dialin.net) (Ping timeout: 260 seconds)
569. # [13:02] * Quits: drublic (~drublic@frbg-4d029775.pool.mediaWays.net) (Remote host closed the connection)
570. # [13:05] * Joins: drublic (~drublic@frbg-4d029775.pool.mediaWays.net)
571. # [13:07] * Quits: karega (~karegaani@cpe-76-184-236-100.tx.res.rr.com) (Ping timeout: 265 seconds)
572. # [13:12] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
573. # [13:14] <hsivonen> annevk: I didn't
574. # [13:14] * Quits: kaustubh (~kaustubh@144.187.36.11) (Read error: Connection reset by peer)
575. # [13:16] <hsivonen> annevk: commented
576. # [13:19] <annevk> if you have a range from x to y, is there a better way to calculate all possible positions than y-x+1?
577. # [13:19] <annevk> the +1 is kind of ugly
578. # [13:19] <roc> you mean a way to write "y - x + 1" that's less ugly?
579. # [13:20] <Ms2ger> y + 1 - x?
580. # [13:20] <Ms2ger> - x + y + 1?
581. # [13:20] <annevk> :)
582. # [13:21] <Ms2ger> (x²-xy+x)/x?
583. # [13:22] <annevk> haha okay
584. # [13:23] <roc> make your ranges closed at the start and open at the end
585. # [13:23] <roc> that usually simplifies code
586. # [13:23] <annevk> not sure what I was thinking of, I just happen to forget the +1 a lot
587. # [13:23] <zcorpan> +1
588. # [13:23] * Joins: richt (richt@nat/opera/x-klwdroihitihkrvo)
589. # [13:24] <annevk> roc: yeah that could work, except with encodings if the lead byte is from 0x81 to 0xFE, using 0xFF everywhere is kind of counter-intuitive too
590. # [13:36] <hsivonen> annevk: c < 0xFF is way more intuitive than c <= 0xFE or c + 1 <= 0xFF
591. # [13:36] <hsivonen> these are integers after all
592. # [13:45] * Joins: kaustubh (~kaustubh@144.187.36.11)
593. # [13:50] * Quits: jondong_ (~jondong@123.126.22.58) (Read error: Connection reset by peer)
594. # [13:50] * Quits: necolas (~necolas@176.251.237.207) (Remote host closed the connection)
595. # [13:51] * Joins: jondong (~jondong@123.126.22.58)
596. # [13:56] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
597. # [13:57] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Client Quit)
598. # [13:57] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
599. # [14:01] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
600. # [14:03] * Quits: [[zz]] (~q@101.108.97.161) (Ping timeout: 246 seconds)
601. # [14:13] * Joins: erichynds (~ehynds@64.206.121.41)
602. # [14:16] * Joins: [[zz]] (~q@125.25.35.54.adsl.dynamic.totbb.net)
603. # [14:21] * JohnAlbin_afk is now known as JohnAlbin
604. # [14:27] <oal> Do I have to pass an ImageData object along with a message to my web worker? new ImageData(61, 61, new CanvasPixelArray()) doesn't seem to work. Also, could I just be using a Uint8Array for this?
605. # [14:30] <annevk> hsivonen: c < FE + 1 is what I have iirc
606. # [14:30] <hsivonen> annevk: eww
607. # [14:30] <annevk> well
608. # [14:30] <hsivonen> annevk: please make that c < 0xFF
609. # [14:30] <annevk> (FE - A1 +1) or some such
610. # [14:31] <gsnedders> oal: A CanvasPixelArray in modern browsers should be a ClampedUint8Array
611. # [14:31] <gsnedders> oal: and you can pass that to/from worker fine
612. # [14:31] <annevk> could make it FF -A1 I guess, dunno
613. # [14:31] <Ms2ger> ImageData doesn't have a constructor, though
614. # [14:33] <oal> Aha, thanks! Let me give it a shot
615. # [14:33] <Ms2ger> Also, Uint8ClampedArray, no?
616. # [14:34] * Joins: karlcow (~karl@nerval.la-grange.net)
617. # [14:34] <gsnedders> Ms2ger: Yeah yeah! :P
618. # [14:34] * Quits: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net) (Ping timeout: 244 seconds)
619. # [14:34] <Ms2ger> Yay, www-style people still consider SGML boolean attributes
620. # [14:35] * gsnedders ended up passing around a CanvasPixelArray if possible, otherwise Array.prototype.slice.call(data), earlier
621. # [14:35] <oal> Hmm, I get "Uncaught ReferenceError: ImageData is not defined", Chromium 17.
622. # [14:36] <Ms2ger> <Ms2ger> ImageData doesn't have a constructor, though
623. # [14:36] <gsnedders> The fall-back doesn't really work in low memory situations, though
624. # [14:36] <Ms2ger> Also, not supported in workers
625. # [14:36] <oal> Oh, I see. So, I should simply use an array with the correct length then?
626. # [14:37] <gsnedders> You can pass around the CanvasPixelArray, not the ImageData.
627. # [14:38] <oal> I'm starting out with an empty canvas anyway, so it wouldn't make much sense to pass that to the worker, then? All drawing will take place in the worker
628. # [14:39] * Joins: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net)
629. # [14:43] * Joins: myakura (~myakura@FL1-110-233-178-43.tky.mesh.ad.jp)
630. # [14:44] * Quits: izhak (~izhak@213.87.241.66) (Remote host closed the connection)
631. # [14:46] * Quits: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl) (Quit: annevk)
632. # [14:49] * Quits: mpt (~mpt@canonical/mpt) (Read error: No route to host)
633. # [14:49] * Joins: mpt (~mpt@nat/canonical/x-vqznelygyeiwjcqq)
634. # [14:49] * Quits: mpt (~mpt@nat/canonical/x-vqznelygyeiwjcqq) (Changing host)
635. # [14:49] * Joins: mpt (~mpt@canonical/mpt)
636. # [14:54] <zcorpan> time for a whatwg weekly?
637. # [14:54] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
638. # [14:56] <karlcow> :)
639. # [14:59] * Quits: kaustubh (~kaustubh@144.187.36.11) (Read error: Connection reset by peer)
640. # [14:59] * Joins: GlitchMr42 (~glitchmr@178-36-179-160.adsl.inetia.pl)
641. # [14:59] * Quits: GlitchMr (~glitchmr@178-36-159-249.adsl.inetia.pl) (Disconnected by services)
642. # [14:59] * GlitchMr42 is now known as GlitchMr
643. # [15:01] <zcorpan> karlcow: s/mentionn/mention/g
644. # [15:05] * karlcow tries to find the context :)
645. # [15:07] <zcorpan> web platform weekly
646. # [15:12] * Joins: kaustubh (~kaustubh@144.187.36.11)
647. # [15:17] <karlcow> ah!!! French getting into the way
648. # [15:18] * Quits: tomasf_ (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf_)
649. # [15:18] <karlcow> zcorpan: fixed! thanks. ☺ will be online in a few minutes.
650. # [15:18] * Joins: scor (~scor@drupal.org/user/52142/view)
651. # [15:18] * Quits: scor (~scor@drupal.org/user/52142/view) (Excess Flood)
652. # [15:19] * Quits: myakura (~myakura@FL1-110-233-178-43.tky.mesh.ad.jp) (Remote host closed the connection)
653. # [15:25] <scott_gonzalez> MikeSmith: We're getting about 4-5 sec run times for the HTML lint scripts.
654. # [15:25] <scott_gonzalez> Per file.
655. # [15:26] <scott_gonzalez> Not sure how much of that is overhead of spawning a new process.
656. # [15:26] <scott_gonzalez> How hard would it be to have the lint scripts accept multiple files?
657. # [15:27] <MikeSmith> scott_gonzalez: hard
658. # [15:27] <scott_gonzalez> hmm...ok
659. # [15:27] <MikeSmith> and most of that is overhead of spawning a new process
660. # [15:28] <MikeSmith> starting up the Java VM each time
661. # [15:28] <MikeSmith> hmm
662. # [15:28] <scott_gonzalez> So if we just had a wrapper around the linters in Java, it should take care of the performance problems?
663. # [15:29] <MikeSmith> I don't know how you would do that
664. # [15:29] <scott_gonzalez> What do the linters take as input?
665. # [15:30] <MikeSmith> the tool that actually does the validation takes a schema file and a HTML file as input
666. # [15:30] <scott_gonzalez> Keep in mind I know nothing about Java...
667. # [15:30] <MikeSmith> well, this isn't doing anything through Java directly
668. # [15:30] <MikeSmith> it's just calling that command-line tool
669. # [15:30] <scott_gonzalez> Right, I'm wondering if we could do it directly through Java and just call whatever the CLI calls internally.
670. # [15:31] <scott_gonzalez> Of course, that would only work if the CLI is really simple and just passes the data off to some other class.
671. # [15:32] * Joins: jzaefferer (~jzaeffere@205.186.165.147)
672. # [15:32] <MikeSmith> even then I don't see any way to do it simply that would not require starting up the jre each and every time
673. # [15:32] <MikeSmith> this is why validator.nu runs as a web service
674. # [15:32] <MikeSmith> well, part of way
675. # [15:32] <MikeSmith> I would really, really like to help you guys set up an instance of the validator.nu backend and have you use that
676. # [15:33] <MikeSmith> you will for most cases see run times of 100ms or so per file, probably
677. # [15:33] * Joins: jdong_bot_ (~jdong_bot@118.186.129.138)
678. # [15:33] <scott_gonzalez> If it were small and simple to include in the jquery-ui repo, we would.
679. # [15:34] <MikeSmith> it just amounts to a bunch of jar files
680. # [15:34] <MikeSmith> if you would be wiling to have the jar files in the rep
681. # [15:34] <MikeSmith> *repo
682. # [15:34] <scott_gonzalez> What kind of total filesize would we be looking at?
683. # [15:34] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 244 seconds)
684. # [15:35] * Joins: smaug____ (~chatzilla@12.197.88.10)
685. # [15:35] <MikeSmith> lemme check and see
686. # [15:37] * Quits: jdong_bot_ (~jdong_bot@118.186.129.138) (Remote host closed the connection)
687. # [15:38] * Joins: jdong_bot_ (~jdong_bot@117.79.233.219)
688. # [15:38] <MikeSmith> for the validator code itself, it would be 4MB
689. # [15:38] <MikeSmith> 8 jar files
690. # [15:39] <MikeSmith> I'll check in the size of the 3rd-party dependencies
691. # [15:42] * Joins: jarek (~jarek@bcu126.neoplus.adsl.tpnet.pl)
692. # [15:42] * Quits: jarek (~jarek@bcu126.neoplus.adsl.tpnet.pl) (Changing host)
693. # [15:42] * Joins: jarek (~jarek@unaffiliated/jarek)
694. # [15:42] <MikeSmith> 28 3rd-party jar files
695. # [15:43] <MikeSmith> checking the size total now
696. # [15:43] * Joins: MacTed (~Thud@63.119.36.36)
697. # [15:44] <MikeSmith> actually, only 16 3rd-party files
698. # [15:45] * Quits: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
699. # [15:46] * Joins: tomasf_ (~tomasf@static-88.131.62.36.addr.tdcsong.se)
700. # [15:47] <MikeSmith> 12MB for the 3rd-party files
701. # [15:47] <MikeSmith> so 16MB total
702. # [15:47] <MikeSmith> scott_gonzalez: ↑
703. # [15:48] * Joins: twisted` (~twisted@p5DDB9C4C.dip.t-dialin.net)
704. # [15:50] <scott_gonzalez> Ok, let's try it out and see how it works.
705. # [15:51] <scott_gonzalez> Can you work with jzaefferer to get us set up with that?
706. # [15:52] <MikeSmith> scott_gonzalez: yeah, absolutely
707. # [15:52] <scott_gonzalez> jzaefferer = Jörn, the other dev lead for jQuery UI
708. # [15:52] <MikeSmith> oh
709. # [15:52] <MikeSmith> OK
710. # [15:52] <MikeSmith> what time zone is he in?
711. # [15:52] <jzaefferer> MikeSmith: would be great if you could put together a build that we can include
712. # [15:52] <MikeSmith> hey jzaefferer
713. # [15:52] <scott_gonzalez> GMT+1, but I'm pretty sure he doesn't sleep :-P
714. # [15:52] <MikeSmith> heh
715. # [15:52] <MikeSmith> jzaefferer: yeah, I'm sure I can put something together for you
716. # [15:53] <jzaefferer> Planning to put that into an npm module, that we'll then include into our grunt build
717. # [15:53] <MikeSmith> ah, OK
718. # [15:53] * Joins: izhak (1000@188.168.203.134)
719. # [15:53] <MikeSmith> there are a couple of minor changes I want to make to the validator code to make it more portable
720. # [15:53] <MikeSmith> I will try to get those done tomorrow
721. # [15:53] <jzaefferer> Whatever the binary ends up looking like, as long as we can somehow pass a list of files to validate and it doesn't take as long, that should work
722. # [15:53] <MikeSmith> pending review from hsivonen
723. # [15:53] <MikeSmith> yeah, we can do that
724. # [15:54] <jzaefferer> OR we implement relaxNG in node/javascript ;)
725. # [15:54] <MikeSmith> heh
726. # [15:54] <MikeSmith> you don't want to do that :)
727. # [15:54] <jzaefferer> yeah...
728. # [15:55] <jzaefferer> well, I'll stick around here, let me know
729. # [15:55] <MikeSmith> and anyway, validator.nu is doing far more than relaxng is capable of on its own
730. # [15:55] <MikeSmith> OK
731. # [15:55] <MikeSmith> to be clear, this will require having a process running and listening on a particular port
732. # [15:55] <MikeSmith> port 8888 by default
733. # [15:55] <MikeSmith> just for the duration of the test run
734. # [15:55] <jzaefferer> okay
735. # [15:56] * Joins: KillerX (~anant@93.158.44.0)
736. # [15:56] <MikeSmith> so I will aim to have it all ready for you guys by end of next week
737. # [15:56] <jzaefferer> as long as that doesn't need any actual network outside of the local machine, that's fine
738. # [15:56] <MikeSmith> yeah, it will all be local
739. # [15:57] <jzaefferer> cool
740. # [15:57] <MikeSmith> there are some things that it normally tries to download from remote hosts when it first starts up, but we already have an option in place to have it use cached copies instead
741. # [15:57] <jzaefferer> nice
742. # [15:57] <MikeSmith> those copies are inside one of the jars
743. # [15:58] * Joins: tomasf__ (~tomasf@host-95-199-30-131.mobileonline.telia.com)
744. # [16:00] * Quits: tomasf_ (~tomasf@static-88.131.62.36.addr.tdcsong.se) (Ping timeout: 264 seconds)
745. # [16:02] * Quits: jwheare (~u2@gateway/web/irccloud.com/x-mhqvtoggalonhkkt) (Quit: Connection closed for inactivity)
746. # [16:06] * Joins: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com)
747. # [16:09] <MikeSmith> hsivonen: if/when you're around and have a minute, wanted to ask you for a sanity check on a couple changes to make it possible to run the validator just from the jar files only, without needing to look for any files on the filesystem
748. # [16:10] * Quits: benschwarz (u2121@gateway/web/irccloud.com/x-mkolaxgzuqlmbook) (Quit: Connection closed for inactivity)
749. # [16:10] <MikeSmith> one is just to have it not look for the validator/log4j.properties but instead set the properties in the code directly
750. # [16:11] * Quits: Ducki (~Ducki@pD9E3935C.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
751. # [16:11] * Quits: KillerX (~anant@93.158.44.0) (Quit: KillerX)
752. # [16:11] <MikeSmith> the other is to have it not look for the local copies of the www.iana.org and wiki.whatwg.org on the filesystem but instead get them from the local-entities jar file
753. # [16:12] * Quits: jdong_bot_ (~jdong_bot@117.79.233.219) (Ping timeout: 246 seconds)
754. # [16:12] <MikeSmith> if you don't have time I'll just e-mail you the actual patches
755. # [16:13] <MikeSmith> immediate reason for the changes is to make it possible for the JQuery UI team to run their tests from just using the jar files
756. # [16:13] <MikeSmith> but more generally to let anybody else be able to do that too
757. # [16:15] <Ms2ger> MikeSmith, Chrome got into an infinite loop again: http://w3c-test.org/framework/results/web-storage-dev/
758. # [16:15] <MikeSmith> no clues
759. # [16:15] <MikeSmith> maybe ping Berjon about it
760. # [16:16] <Ms2ger> And segfaulted now, yay Chrome!
761. # [16:16] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 272 seconds)
762. # [16:16] <MikeSmith> oh man
763. # [16:18] * Ms2ger blames Google
764. # [16:19] <Ms2ger> Hrm
765. # [16:19] <Ms2ger> That doesn't explain why Opera has the same issue, though
766. # [16:20] <MikeSmith> same issue?
767. # [16:20] <MikeSmith> the loop problem?
768. # [16:20] <Ms2ger> Yep
769. # [16:21] <Ms2ger> Seems there's something wrong with the "run in most-needed order"
770. # [16:21] <jarek> should there be classList property on SVG elements?
771. # [16:21] <jarek> Firefox implements it, but Chrome does not
772. # [16:22] <Ms2ger> Yes
773. # [16:22] <Ms2ger> It's on Element in DOM Core
774. # [16:22] <jarek> but SVGElement.prototype.classList is not standardized, right?
775. # [16:22] <jarek> it's in DOM Core? I though I have seen it in HTML5 spec
776. # [16:22] <Ms2ger> Sure
777. # [16:22] <Ms2ger> It used to be in HTML
778. # [16:23] * Quits: richt (richt@nat/opera/x-klwdroihitihkrvo) (Remote host closed the connection)
779. # [16:24] * Joins: GlitchMr42 (~glitchmr@178-36-142-9.adsl.inetia.pl)
780. # [16:24] * Quits: GlitchMr (~glitchmr@178-36-179-160.adsl.inetia.pl) (Ping timeout: 240 seconds)
781. # [16:25] * Joins: myakura (~myakura@FL1-110-233-178-43.tky.mesh.ad.jp)
782. # [16:26] * Quits: charlvn (~charlvn@2002:8259:81f2::1) (Quit: leaving)
783. # [16:26] * Quits: kaustubh (~kaustubh@144.187.36.11) (Quit: Leaving...!)
784. # [16:30] * Joins: esc_ (~esc_ape@178.112.148.206.wireless.dyn.drei.com)
785. # [16:30] * Quits: Jedi_ (~Jedi@jedi.org) (Ping timeout: 246 seconds)
786. # [16:33] * Quits: erichynds (~ehynds@64.206.121.41)
787. # [16:33] * Joins: jryans (~jryans@24-155-144-5.static.grandenetworks.net)
788. # [16:34] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
789. # [16:36] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
790. # [16:36] * Joins: jdong_bot_ (~jdong_bot@117.79.233.219)
791. # [16:37] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: Leaving)
792. # [16:42] * Quits: jdong_bot_ (~jdong_bot@117.79.233.219) (Remote host closed the connection)
793. # [16:43] * Quits: tomasf__ (~tomasf@host-95-199-30-131.mobileonline.telia.com) (Quit: tomasf__)
794. # [16:44] * Joins: chriseppstein (~chrisepps@209.119.65.162)
795. # [16:45] * Joins: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl)
796. # [16:48] <annevk> why would you want to operate on local name?
797. # [16:48] <annevk> everything that ignores namespaces operates on name thus far
798. # [16:48] <Ms2ger> Say what?
799. # [16:48] <annevk> context: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16563
800. # [16:49] * Quits: GlitchMr42 (~glitchmr@178-36-142-9.adsl.inetia.pl) (Read error: Connection reset by peer)
801. # [16:49] <Ms2ger> smaug____,
802. # [16:49] * Joins: GlitchMr42 (~glitchmr@178-36-142-9.adsl.inetia.pl)
803. # [16:49] * Joins: cpearce (~cpearce@ip-118-90-36-173.xdsl.xnet.co.nz)
804. # [16:50] * Joins: sarro (~sarro@i5E8650E9.versanet.de)
805. # [16:50] * Quits: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de) (Read error: Connection reset by peer)
806. # [16:51] <annevk> hmm WHATWG Weekly
807. # [16:51] <annevk> okay, if I can write it in 40 min
808. # [16:51] <annevk> so
809. # [16:51] <smaug____> annevk: if you set attribute
810. # [16:51] <annevk> lots of canvas
811. # [16:51] <smaug____> you don't care about prefix
812. # [16:51] <smaug____> you care about namespace and localName
813. # [16:51] <annevk> smaug____: setAttribute("xlink:href", "test")
814. # [16:51] <annevk> try it
815. # [16:52] <annevk> if the element has an attribute xlink:href in the xlink namespace declared...
816. # [16:53] * Quits: tomasf (~tom@2002:55e5:dbb7:0:1938:1947:dd20:55f0) (Read error: Connection reset by peer)
817. # [16:54] <smaug____> so ?
818. # [16:58] * Quits: ivan\ (~ivan@unaffiliated/ivan/x-000001) (Ping timeout: 252 seconds)
819. # [16:58] * Joins: tantek (~tantek@c-76-115-51-221.hsd1.or.comcast.net)
820. # [16:58] * Joins: chayin_ (quassel@nat/nokia/x-wpnnhgbrdkccnyfn)
821. # [16:58] * Quits: izhak (1000@188.168.203.134) (Read error: Connection reset by peer)
822. # [16:58] * Joins: izhak (1000@188.168.203.134)
823. # [16:59] * Quits: chayin (quassel@nat/nokia/x-ugptjjmuesahrnpi) (Ping timeout: 252 seconds)
824. # [17:00] * Joins: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
825. # [17:01] * Parts: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
826. # [17:01] * Joins: erichynds (~ehynds@64.206.121.41)
827. # [17:03] * Quits: tantek (~tantek@c-76-115-51-221.hsd1.or.comcast.net) (Ping timeout: 260 seconds)
828. # [17:05] * Quits: smaug____ (~chatzilla@12.197.88.10) (Ping timeout: 252 seconds)
829. # [17:06] * Joins: GlitchMr (~glitchmr@178-36-3-38.adsl.inetia.pl)
830. # [17:06] * Joins: ivan\ (~ivan@unaffiliated/ivan/x-000001)
831. # [17:07] * nonge_ is now known as nonge
832. # [17:09] * Quits: GlitchMr42 (~glitchmr@178-36-142-9.adsl.inetia.pl) (Ping timeout: 264 seconds)
833. # [17:11] * Joins: smaug____ (~chatzilla@12.197.88.252)
834. # [17:20] * Quits: bentruyman (~bentruyma@li159-104.members.linode.com) (Quit: ZNC - http://znc.sourceforge.net)
835. # [17:22] * Joins: ehsan (~ehsan@12.197.88.10)
836. # [17:22] * Quits: cpearce (~cpearce@ip-118-90-36-173.xdsl.xnet.co.nz) (Ping timeout: 240 seconds)
837. # [17:26] * Joins: tantek (~tantek@c-76-115-51-221.hsd1.or.comcast.net)
838. # [17:27] * Quits: nonge (~nonge@p5082B19C.dip.t-dialin.net) (Quit: Verlassend)
839. # [17:28] <annevk> rough draft: http://blog.whatwg.org/weekly-canvas-v5
840. # [17:29] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: brb)
841. # [17:31] * Joins: bentruyman (~bentruyma@li159-104.members.linode.com)
842. # [17:33] <annevk> smaug____: well it works with name there, not local name...
843. # [17:33] <smaug____> and the question I had is, so ?
844. # [17:33] <smaug____> :)
845. # [17:34] <annevk> everything that ignores namespaces operates on name thus far
846. # [17:34] <annevk> seems kind of weird to have that different here
847. # [17:34] <MikeSmith> annevk: s/devices as that the vast/devices, as the vast/
848. # [17:35] <smaug____> if you are handling namespaces, you really don't want to care of the prefixes
849. # [17:35] <smaug____> you have namespace and localName
850. # [17:35] <annevk> thanks MikeSmith
851. # [17:35] <smaug____> (but I'm just in middle of something else...)
852. # [17:36] <annevk> that's true enough, but I thought we didn't care about namespaces?
853. # [17:36] <annevk> but I guess then we should not have attributeNamespace either hmm
854. # [17:36] * Quits: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net) (Ping timeout: 276 seconds)
855. # [17:36] <annevk> annoying
856. # [17:37] <smaug____> oh yes, namespaced attributes are very annoying
857. # [17:40] * Quits: ehsan (~ehsan@12.197.88.10) (Remote host closed the connection)
858. # [17:57] * Joins: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net)
859. # [18:01] * Quits: Lachy (Lachy@nat/opera/x-pzcnpaxcmjvicyyv) (Quit: Computer has gone to sleep.)
860. # [18:02] * Quits: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net) (Ping timeout: 245 seconds)
861. # [18:12] * Joins: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net)
862. # [18:13] * Joins: maikmerten (~maikmerte@port-92-201-19-125.dynamic.qsc.de)
863. # [18:17] * Joins: nessy (Adium@nat/google/x-qzcizevaowdeyasx)
864. # [18:18] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
865. # [18:25] * Joins: dbaron (~dbaron@12.197.88.252)
866. # [18:28] * Quits: mattwest (~textual@host81-149-171-23.in-addr.btopenworld.com) (Quit: ["Textual IRC Client: www.textualapp.com"])
867. # [18:30] * Joins: GlitchMr42 (~glitchmr@178-36-158-60.adsl.inetia.pl)
868. # [18:33] * Quits: GlitchMr (~glitchmr@178-36-3-38.adsl.inetia.pl) (Ping timeout: 264 seconds)
869. # [18:35] * Joins: scor (~scor@drupal.org/user/52142/view)
870. # [18:37] * Quits: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net) (Ping timeout: 272 seconds)
871. # [18:38] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
872. # [18:43] * Quits: PalleZingmark (~Adium@217.13.228.226) (Quit: Leaving.)
873. # [18:48] * GlitchMr42 is now known as GlitchMr
874. # [18:57] * Joins: dave_levin (dave_levin@nat/google/x-anuvdktnuseibxip)
875. # [19:02] * Quits: Neocortex (~niels@82-170-160-25.ip.telfort.nl) (Remote host closed the connection)
876. # [19:13] * Quits: myakura (~myakura@FL1-110-233-178-43.tky.mesh.ad.jp) (Remote host closed the connection)
877. # [19:13] * Quits: drublic (~drublic@frbg-4d029775.pool.mediaWays.net) (Remote host closed the connection)
878. # [19:16] * jonlee|afk is now known as jonlee
879. # [19:17] * Quits: izhak (1000@188.168.203.134) (Remote host closed the connection)
880. # [19:18] * Joins: izhak (1000@188.168.203.134)
881. # [19:21] * Joins: VernonK (c74441eb@gateway/web/freenode/ip.199.68.65.235)
882. # [19:25] * Joins: jdaggett (~jdaggett@12.197.88.252)
883. # [19:26] <dglazkov> good morning, Whatwg!
884. # [19:26] <dglazkov> and good night, Ms2ger
885. # [19:26] <Ms2ger> Morning, dglazkov
886. # [19:27] <dglazkov> now you're just messing with me
887. # [19:29] * Joins: sicking (~chatzilla@12.197.88.252)
888. # [19:30] * Parts: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
889. # [19:32] * Parts: VernonK (c74441eb@gateway/web/freenode/ip.199.68.65.235)
890. # [19:33] * Quits: sicking (~chatzilla@12.197.88.252) (Ping timeout: 260 seconds)
891. # [19:39] * Joins: ap (~ap@2620:149:4:1b01:6467:9589:3f61:4494)
892. # [19:44] * Joins: pablof (~pablof@144.189.101.1)
893. # [19:45] * Joins: WeirdAl (~chatzilla@g2spf.ask.info)
894. # [19:49] <TabAtkins> Ms2ger: What's this about SGML boolean attributes?
895. # [19:49] * Joins: drublic (~drublic@frbg-5d84ee5f.pool.mediaWays.net)
896. # [19:51] <Ms2ger> http://lists.w3.org/Archives/Public/www-style/2012Mar/0667.html
897. # [19:52] <TabAtkins> Note: Christoph is not part of the WG. He's one of the many contributors, and sometimes gets strange ideas.
898. # [19:53] * Joins: myakura (~myakura@FL1-110-233-178-43.tky.mesh.ad.jp)
899. # [19:53] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
900. # [19:56] * Joins: stalled (~stalled@unaffiliated/stalled)
901. # [19:58] <Ms2ger> Note: I said "www-style", not "The Cabal"
902. # [19:58] <hober> Hixie: in http://lists.w3.org/Archives/Public/public-html/2012Mar/0739.html rubys asked me to "obtain and incorporate any feedback you feel is necessary from the editor" on my counter proposal on the web+ prefix issue: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-189
903. # [19:58] <hober> Hixie: so, yeah. let me know if you have any thoughts on that.
904. # [20:01] * Joins: davidb (~davidb@65.93.94.10)
905. # [20:03] <Ms2ger> So, when doing for (var p in obj), where obj supports both indexed and named properties, which values should p take?
906. # [20:03] <gsnedders> Ms2ger: For WebIDL?
907. # [20:04] <Ms2ger> Hmm?
908. # [20:05] <gsnedders> Ms2ger: A WebIDL-defined object, or a general ES one?
909. # [20:05] <Ms2ger> Former
910. # [20:06] * Joins: jsbell (jsbell@nat/google/x-xifumtgrgjmqrdnj)
911. # [20:11] <gnarf> hey WG guys... newz2000 over on #html5 was bringing up a feature that could be pretty handy in the future... Some way to detect/convey the current user's locale preferences in JavaScript
912. # [20:11] <Ms2ger> No
913. # [20:12] <Ms2ger> That's a privacy bug, not a feature
914. # [20:12] <gsnedders> Already sent over HTTP, though
915. # [20:12] * Joins: newz2000 (~newz2000@unaffiliated/newz2000)
916. # [20:12] <gnarf> sent on EVERY http connection
917. # [20:12] <gnarf> privacy my ass
918. # [20:12] <gnarf> (sorry)
919. # [20:12] * Quits: maikmerten (~maikmerte@port-92-201-19-125.dynamic.qsc.de) (Remote host closed the connection)
920. # [20:13] <newz2000> hi, sorry I missed the first part of the discussion
921. # [20:13] <newz2000> I see in gecko 5+ the first value of the user's preferred lang is available in navigator.language
922. # [20:13] <newz2000> that's an awesome improvement
923. # [20:14] <newz2000> I suspect it only returns the first value because of backwards compatibility
924. # [20:14] <newz2000> and it's not in the same format as the http header
925. # [20:15] <gsnedders> The sensible format would surely be an array of language tags?
926. # [20:15] <newz2000> that would be better than the string format that gets sent as part of the http header
927. # [20:15] <newz2000> the http header includes a weighting value
928. # [20:16] <newz2000> even if we only had the string value though it would be an improvement, it's pretty easily parsed.
929. # [20:17] <newz2000> This was annoying a couple years ago, but in recent times client side templating is becoming more common
930. # [20:17] <newz2000> and therefore localization of some resources can be done client side, except that you've got to use tricks to go to the server and find out what language is being sent in the http header
931. # [20:18] <newz2000> I'd be happy to file bugs or some thing else to start productive conversation of the issue
932. # [20:18] <newz2000> what is the best process?
933. # [20:21] * Joins: sicking (~chatzilla@12.197.88.252)
934. # [20:22] * jonlee is now known as jonlee|afk
935. # [20:24] * Joins: necolas (~necolas@b0fbedcf.bb.sky.com)
936. # [20:26] * Quits: izhak (1000@188.168.203.134) (Ping timeout: 244 seconds)
937. # [20:28] <TabAtkins> newz2000: This isn't a good room to discuss Gecko specifics, except insofar as it's relevant to specs.
938. # [20:28] <TabAtkins> newz2000: But if you want to file bugs or something, go for it.
939. # [20:28] <newz2000> well, my hope is to get all browsers to provide a common way
940. # [20:29] <newz2000> none give all the info but a recent version of ff gives a little info and I hear IE does too.
941. # [20:29] <TabAtkins> Oh, I see. I skimmed past your wall of text. ^_^
942. # [20:29] <newz2000> Yeah, maybe a mailing list post would be better, though it looks to be a pretty high volume list
943. # [20:30] * jonlee|afk is now known as jonlee
944. # [20:33] <TabAtkins> Just send a post to whatwg@whatwg.org
945. # [20:33] <newz2000> ok.
946. # [20:33] <newz2000> Thanks for the encouragement TabAtkins
947. # [20:37] * Joins: jwalden (~waldo@c-71-202-165-226.hsd1.ca.comcast.net)
948. # [20:41] * Quits: tantek (~tantek@c-76-115-51-221.hsd1.or.comcast.net) (Quit: tantek)
949. # [20:42] <kennyluck> Perhaps I shouldn't say this but from time to time Christoph's mails do make me laugh.
950. # [20:43] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
951. # [20:45] <TabAtkins> He's clearly on the "theoretical" side of the specturm.
952. # [20:48] * Quits: myakura (~myakura@FL1-110-233-178-43.tky.mesh.ad.jp) (Remote host closed the connection)
953. # [21:00] * Quits: jryans (~jryans@24-155-144-5.static.grandenetworks.net) (Quit: Leaving...)
954. # [21:06] * Joins: mattwest (~textual@host-92-26-128-169.as13285.net)
955. # [21:19] * Quits: WeirdAl (~chatzilla@g2spf.ask.info) (Quit: ChatZilla 0.9.88.1 [Firefox 11.0/20120312181643])
956. # [21:19] * Joins: ehsan (~ehsan@12.197.88.252)
957. # [21:21] * Joins: karlcow (~karl@nerval.la-grange.net)
958. # [21:24] * Quits: jwalden (~waldo@c-71-202-165-226.hsd1.ca.comcast.net) (Quit: bbiab)
959. # [21:31] * Quits: dbaron (~dbaron@12.197.88.252) (Quit: 8403864 bytes have been tenured, next gc will be global.)
960. # [21:34] * Quits: smaug____ (~chatzilla@12.197.88.252) (Ping timeout: 272 seconds)
961. # [21:37] * Joins: tomasf (~tom@2002:55e5:dbb7:0:3083:b4f2:f51b:9148)
962. # [21:38] * Quits: tomasf (~tom@2002:55e5:dbb7:0:3083:b4f2:f51b:9148) (Client Quit)
963. # [21:38] * Joins: tomasf (~tom@c-b7dbe555.024-204-6c6b7012.cust.bredbandsbolaget.se)
964. # [21:42] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Quit: rniwa)
965. # [21:43] <annevk> Ms2ger: hmm yeah
966. # [21:43] <annevk> Ms2ger: the whole named property business needs a careful look
967. # [21:45] * Quits: roc (~chatzilla@121.98.230.221) (Ping timeout: 276 seconds)
968. # [21:45] <Ms2ger> Yeah
969. # [21:45] <Ms2ger> No spec that I know of actually defines the order
970. # [21:48] * Joins: smaug____ (~chatzilla@12.197.88.252)
971. # [21:49] * Quits: smaug____ (~chatzilla@12.197.88.252) (Client Quit)
972. # [21:49] * Joins: smaug____ (~chatzilla@12.197.88.252)
973. # [21:52] * Quits: LBP (~Mirc@pD9EB1505.dip0.t-ipconnect.de) (Quit: Bye, bye! See you on http://leanbackplayer.com)
974. # [21:57] * heycam|away is now known as heycam
975. # [21:57] * Quits: GlitchMr (~glitchmr@178-36-158-60.adsl.inetia.pl) (Read error: Connection reset by peer)
976. # [22:00] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
977. # [22:03] * Quits: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no) (Remote host closed the connection)
978. # [22:18] <annevk> http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ because script scheduling was not complicated enough just yet?
979. # [22:18] <annevk> kind of makes importScripts obsolete though I guess
980. # [22:19] <annevk> s/though//
981. # [22:21] <MikeSmith> http://www.belshe.com/2012/03/29/comments-on-microsofts-spdy-proposal/
982. # [22:22] <Ms2ger> I like how the one comment talks about "HTML + Mobility"
983. # [22:27] * Joins: roc (~chatzilla@60.234.54.74)
984. # [22:28] * Joins: micheil (~micheil@94.197.127.90.threembb.co.uk)
985. # [22:29] * Joins: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net)
986. # [22:29] * Joins: dbaron (~dbaron@12.197.88.252)
987. # [22:30] * Joins: rniwa (rniwa@nat/google/x-stuoidrhpjbpwqzi)
988. # [22:41] * Quits: tomasf (~tom@c-b7dbe555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Quit: tomasf)
989. # [22:41] * Joins: eseidel (u5595@gateway/web/irccloud.com/x-kadejnkgvqgcgxbq)
990. # [22:42] <eseidel> Curious if anyone here has knowledge of <iframe seamless=true>. Either attempted implementing it, or worked on the spec?
991. # [22:42] <eseidel> (besides Hixie of course)
992. # [22:43] <MikeSmith> eseidel: no browser projects have attempted to implement it yet, afaik
993. # [22:43] * Joins: cpearce (~cpearce@ip-118-90-36-173.xdsl.xnet.co.nz)
994. # [22:43] <MikeSmith> eseidel: btw, that sentence you cite seems grammatical to me
995. # [22:43] <MikeSmith> though long
996. # [22:43] <eseidel> MikeSmith: it took my little brain quite a while to parse
997. # [22:43] <eseidel> MikeSmith: I'm not doubting it's english :)
998. # [22:43] <eseidel> (or gramatical)
999. # [22:43] <MikeSmith> heh
1000. # [22:44] <Ms2ger> <iframe seamless>, you mean, I guess
1001. # [22:44] <eseidel> just infinite
1002. # [22:44] <MikeSmith> en-US-hixie
1003. # [22:44] <eseidel> MikeSmith, Ms2ger are either of you familiar with the spec, enough to field questions?
1004. # [22:44] <eseidel> I'm looking (briefly) at what it would take in WebKit
1005. # [22:44] <Ms2ger> I'm not familiar, but feel free to bat me a question :)
1006. # [22:44] <TabAtkins> I'm roughly familiar with the spec.
1007. # [22:45] <MikeSmith> eseidel: https://bugzilla.mozilla.org/show_bug.cgi?id=631218 fwiw
1008. # [22:46] <eseidel> MikeSmith: k
1009. # [22:46] <eseidel> MikeSmith: it appears https://bugs.webkit.org/show_bug.cgi?id=45950 is ours
1010. # [22:48] * Quits: erichynds (~ehynds@64.206.121.41)
1011. # [22:48] <eseidel> TabAtkins: first question: re: the CSS parts. I assume it's only that the "root style" of the inner document as it would be for a child of the iframe's parent. NOT that global styles from the parent docuemnt apply to the inner document? (such as a body { } selector?)
1012. # [22:48] <Ms2ger> I believe you assume wrong
1013. # [22:49] <Ms2ger> Or I may be parsing you wrongly :)
1014. # [22:49] <TabAtkins> eseidel: Selectors never match across the boundary.
1015. # [22:49] <eseidel> good
1016. # [22:49] <TabAtkins> Inheritance crosses the boundary, and user stylesheets ae cloned across the boundary.
1017. # [22:49] <Ms2ger> Or I'm plain wrong
1018. # [22:49] <annevk> I thought that was the whole point
1019. # [22:50] <eseidel> but, all selectors that might apply to the <iframe> or it's kids, are part of the style inherited by the inner-doucment's root
1020. # [22:50] <annevk> that Selectors cross the boundary
1021. # [22:50] <TabAtkins> (Wholely cloned, not haing their selectors apply across.)
1022. # [22:50] <TabAtkins> Selectors targetting the <iframe>'s children do nothing.
1023. # [22:50] <TabAtkins> The nested document inherits from the <iframe> element itself only.
1024. # [22:51] <eseidel> iframe:first-child { color: red } would not target the inner doc?
1025. # [22:51] <Ms2ger> You means iframe > foo?
1026. # [22:51] <eseidel> if, so that makes things super easy
1027. # [22:51] <TabAtkins> eseidel: Correctly.
1028. # [22:51] <Ms2ger> Because that wouldn't make sense
1029. # [22:51] <eseidel> from a CSS perspective
1030. # [22:51] <TabAtkins> Or rather, "iframe:first-child" would, because that still targets the iframe.
1031. # [22:51] <eseidel> OK, so it sounds like the CSS side is simple
1032. # [22:51] <Ms2ger> body {} would match the inner document's body, no?
1033. # [22:51] <TabAtkins> But "iframe > :first-child" doesn't.
1034. # [22:51] <TabAtkins> Ms2ger: No.
1035. # [22:51] <TabAtkins> Go read the spec. ^_^
1036. # [22:51] <eseidel> the spec only really enumerates what it does do :)
1037. # [22:52] <eseidel> the first two points state the 2 CSS parts
1038. # [22:52] <TabAtkins> eseidel: Yes, and thus it doesn't do anything else.
1039. # [22:52] <Ms2ger> In a CSS-supporting user agent: the user agent must add all the style sheets that apply to the iframe element to the cascade of the active document of the iframe element's nested browsing context, at the appropriate cascade levels, before any style sheets specified by the document itself.
1040. # [22:52] * JohnAlbin is now known as JohnAlbin_zzzzzz
1041. # [22:52] <eseidel> http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless
1042. # [22:52] <TabAtkins> Ms2ger: Oh, duh, now I understand your question. Yes.
1043. # [22:52] <Ms2ger> Then why did you say No?
1044. # [22:52] <TabAtkins> The stylesheet gets cloned over into the iframe's document, so yeah, a "body" selector in the outer document will also match the <body> in the ref'd document.
1045. # [22:52] <eseidel> ok, so I misunderstood too then
1046. # [22:53] <eseidel> ok
1047. # [22:53] <TabAtkins> Ms2ger: Because I thought you were saying something else.
1048. # [22:53] <eseidel> so that's a bit weird
1049. # [22:53] <Ms2ger> I wonder what you managed to read into that, then :)
1050. # [22:53] <eseidel> and may be difficult
1051. # [22:53] <TabAtkins> Ms2ger: I"m not sure.
1052. # [22:53] <eseidel> TabAtkins: are these stylesheets accessible from teh inner document?
1053. # [22:53] <eseidel> TabAtkins: are they cloned?
1054. # [22:53] <TabAtkins> eseidel: No.
1055. # [22:53] <TabAtkins> They just apply in the cascade before the doc's own stylesheets.
1056. # [22:53] <eseidel> TabAtkins: are they live? such that modification to them by the outer document effects the inner?
1057. # [22:53] <TabAtkins> But they're not visible.
1058. # [22:53] <TabAtkins> Yes, they're live.
1059. # [22:53] * Joins: JohnAlbin (~JohnAlbin@114-42-51-24.dynamic.hinet.net)
1060. # [22:54] * Joins: eseidel2 (~eseidel@173-164-128-209-SFBA.hfc.comcastbusiness.net)
1061. # [22:54] <eseidel2> TabAtkins: sorry, irc cloud is being stupid
1062. # [22:54] <eseidel2> TabAtkins: I was asking:
1063. # [22:55] <eseidel2> eseidel> TabAtkins: are these stylesheets accessible from teh inner document?
1064. # [22:55] <eseidel2> 1:46 PM <eseidel> TabAtkins: are they cloned?
1065. # [22:55] <eseidel2> 1:46 PM <eseidel> TabAtkins: are they live? such that modification to them by the outer document effects the inner?
1066. # [22:55] <Ms2ger> <TabAtkins> eseidel: No.
1067. # [22:55] <Ms2ger> <TabAtkins> They just apply in the cascade before the doc's own stylesheets.
1068. # [22:55] <Ms2ger> <eseidel> TabAtkins: are they live? such that modification to them by the outer document effects the inner?
1069. # [22:55] <Ms2ger> <TabAtkins> But they're not visible.
1070. # [22:55] <Ms2ger> <TabAtkins> Yes, they're live.
1071. # [22:55] <TabAtkins> Thanks, Ms2ger .
1072. # [22:55] <eseidel2> ok
1073. # [22:55] <Ms2ger> Np
1074. # [22:55] <eseidel2> so that's easier
1075. # [22:55] <TabAtkins> Tehy're not literally cloned, just spammed into the cascade.
1076. # [22:55] <ojan> TabAtkins: what are the use-cases for :empty? Could we just make :empty match nodes that only contain non-significant whitespace?
1077. # [22:55] <ojan> TabAtkins: alternately, i guess we could add a :collapsed pseudo
1078. # [22:55] <TabAtkins> ojan: I really don't know what the use-case was.
1079. # [22:56] <eseidel2> TabAtkins: yeah, that's fine
1080. # [22:56] <annevk> I think :empty might have been for empty table cells
1081. # [22:56] * JohnAlbin is now known as JohnAlbinZZZZZZZ
1082. # [22:56] <ojan> annevk: oh, could be
1083. # [22:56] * Quits: JohnAlbin_zzzzzz (~JohnAlbin@114-42-63-53.dynamic.hinet.net) (Ping timeout: 245 seconds)
1084. # [22:57] <eseidel2> so TabAtkins , it seems the second bullet does not support the iframe:first-child { } selector matching anything in the inner document
1085. # [22:57] <eseidel2> TabAtkins: that's your interpretation, correct?
1086. # [22:57] <TabAtkins> ojan: I suspect that "insignificant white-space" would be okay for :empty, fi the spec was changed.
1087. # [22:57] * Quits: mattwest (~textual@host-92-26-128-169.as13285.net) (Quit: ["Textual IRC Client: www.textualapp.com"])
1088. # [22:57] <eseidel2> TabAtkins: that iframe:first-child { } matches nothing in the inner document (unless of course there is an iframe in that inner document with a child)
1089. # [22:57] <TabAtkins> eseidel2: Your selector is wrong. ^_^ If you meant "iframe > :first-child", then yes.
1090. # [22:58] <TabAtkins> Yes.
1091. # [22:58] <eseidel2> TabAtkins: my little CSS brain can't parse that anymore. long since paged out all mys elector knowledge
1092. # [22:58] * JohnAlbinZZZZZZZ is now known as jXhnXlbXn
1093. # [22:58] <eseidel2> TabAtkins: that's a defendant of :first-child ?
1094. # [22:58] * Joins: abarth_ (~abarth@2002:ada4:80d1:0:c5be:aabe:2932:5d4d)
1095. # [22:58] <TabAtkins> iframe:first-child means "an iframe who is a first child".
1096. # [22:58] <eseidel2> decendant
1097. # [22:58] <eseidel2> oh, you're right
1098. # [22:58] <eseidel2> I want, first child of the frame
1099. # [22:58] <eseidel2> so iframe > :first-child then?
1100. # [22:58] <TabAtkins> Yeah, that won't "cross over" and select the first element in the ref'd doc.
1101. # [22:59] <eseidel2> ok, good
1102. # [22:59] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 244 seconds)
1103. # [22:59] * jXhnXlbXn is now known as JohnAlbin_sleep
1104. # [22:59] <TabAtkins> Ooh, interesting diversion here. What happens with @seamless and a <style scoped> on an ancestor?
1105. # [22:59] <eseidel2> TabAtkins: so the 3rd bullet is just saying that the root element of the inner doc inherits from the iframe's style
1106. # [22:59] <TabAtkins> yup
1107. # [23:00] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
1108. # [23:00] <TabAtkins> Actually, I answered my own question. The scoped stylesheet is just spammed into the cascade as normal, without carrying over any scoping semantics.
1109. # [23:00] * Quits: rniwa (rniwa@nat/google/x-stuoidrhpjbpwqzi) (Remote host closed the connection)
1110. # [23:00] <TabAtkins> Which will be weird with :scope selectors or whatever.
1111. # [23:01] * Joins: rniwa (rniwa@nat/google/x-kjdufyikfrjpfqmx)
1112. # [23:01] <TabAtkins> I should raise an issue.
1113. # [23:01] <Ms2ger> And take over editing this stuff ;)
1114. # [23:02] <eseidel2> TabAtkins: so iframe still remains a replaced element
1115. # [23:02] <eseidel2> TabAtkins: it just magically acts like a block
1116. # [23:02] <eseidel2> in a manual hacky way
1117. # [23:02] <TabAtkins> eseidel2: Yes.
1118. # [23:03] <eseidel2> TabAtkins: so it behaves like a hacky inline-block of sorts?
1119. # [23:03] <eseidel2> i guess not quite
1120. # [23:03] <eseidel2> since inline block doesn't have width: auto?
1121. # [23:03] <eseidel2> I don't' remember, actually
1122. # [23:04] <TabAtkins> inline-block's width:auto translates to 'fit-content'.
1123. # [23:04] <TabAtkins> While block's width:auto translates to 'fill' or whatever.
1124. # [23:06] * Quits: eric_carlson (~eric@2620:149:4:1b01:20e0:60ba:94ff:ab03) (Quit: eric_carlson)
1125. # [23:08] * Joins: eric_carlson (~eric@2620:149:4:1b01:b5cf:46d3:e105:6204)
1126. # [23:08] <MikeSmith> http://www.w3.org/News/2012#entry-9404
1127. # [23:08] <MikeSmith> publication announcement for the HTML WG TR drafts
1128. # [23:09] <Ms2ger> This month?!
1129. # [23:10] <hober> whooo!
1130. # [23:10] <paul_irish> \o/ MikeSmith
1131. # [23:10] <Ms2ger> Yay for having a slightly less obsolete document on TR/!
1132. # [23:10] <MikeSmith> heh
1133. # [23:11] * Quits: eric_carlson (~eric@2620:149:4:1b01:b5cf:46d3:e105:6204) (Client Quit)
1134. # [23:11] * Joins: eric_carlson (~eric@2620:149:4:1b01:b5cf:46d3:e105:6204)
1135. # [23:12] * Quits: kennyluck (~kennyluck@114-43-114-47.dynamic.hinet.net) (Ping timeout: 265 seconds)
1136. # [23:12] <MikeSmith> it would be good to use this to give web developers a heads-up about the updates to the APIs section of the diff-from-HTML4 document
1137. # [23:12] <MikeSmith> http://www.w3.org/TR/2012/WD-html5-diff-20120329/#apis
1138. # [23:13] <MikeSmith> zcorpan added all kinds of awesome to that
1139. # [23:14] <MikeSmith> along with massively detailed section about what's changed over the last 12 months
1140. # [23:14] <MikeSmith> http://www.w3.org/TR/2012/WD-html5-diff-20120329/#changes-2011-05-25
1141. # [23:14] <MikeSmith> or 10 months
1142. # [23:16] * Joins: kennyluck (~kennyluck@114-43-124-112.dynamic.hinet.net)
1143. # [23:18] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
1144. # [23:18] * Quits: davidb (~davidb@65.93.94.10) (Quit: davidb)
1145. # [23:19] * Joins: stalled (~stalled@unaffiliated/stalled)
1146. # [23:20] * Quits: jernoble (~jernoble@2620:149:4:1b01:20d0:534b:97e6:88df) (Remote host closed the connection)
1147. # [23:20] * Joins: jernoble (~jernoble@2620:149:4:1b01:2173:7e76:93ee:7540)
1148. # [23:22] * Quits: jernoble (~jernoble@2620:149:4:1b01:2173:7e76:93ee:7540) (Remote host closed the connection)
1149. # [23:22] * Joins: jernoble (~jernoble@2620:149:4:1b01:2173:7e76:93ee:7540)
1150. # [23:25] * Joins: karlcow (~karl@nerval.la-grange.net)
1151. # [23:28] <karlcow> → curl -sI http://hansmuller-webkit.blogspot.ca/2012/03/css-transform-origin-coming-to-svg.html | grep Content-Type
1152. # [23:28] <karlcow> Content-Type: text/html; charset=UTF-8
1153. # [23:28] <karlcow> I wonder why blogspot call that HTML
1154. # [23:28] <karlcow> it is barely HTML
1155. # [23:29] <karlcow> there is a tendency to send big JSON files packages in an pseudo HTML UI
1156. # [23:29] <karlcow> jux.com does that too
1157. # [23:31] <gsnedders> Old New Twitter.com did too, not looked at source of New New Twitter
1158. # [23:32] * Quits: cpearce (~cpearce@ip-118-90-36-173.xdsl.xnet.co.nz) (Ping timeout: 252 seconds)
1159. # [23:32] <karlcow> really silly for blog posts.
1160. # [23:32] <karlcow> You do a save as of the page
1161. # [23:32] <karlcow> save it as html
1162. # [23:32] <karlcow> then try to load it in your browser later on
1163. # [23:32] <karlcow> BLANK PAGE
1164. # [23:33] <karlcow> nothing
1165. # [23:33] * Quits: jernoble (~jernoble@2620:149:4:1b01:2173:7e76:93ee:7540) (Quit: jernoble)
1166. # [23:37] <karlcow> as a matter of facts the most reliable way to access the content seems to be the feed http://hansmuller-webkit.blogspot.ca/feeds/posts/default
1167. # [23:37] * Joins: sedovsek_ (~robert@93-103-90-17.dynamic.t-2.net)
1168. # [23:38] * Quits: sedovsek_ (~robert@93-103-90-17.dynamic.t-2.net) (Client Quit)
1169. # [23:38] <TabAtkins> karlcow: The most reliable way to save a page is to open up developer tools, right click on the <html> element, and select "copy as html". Then paste into a text file yourself.
1170. # [23:38] * Quits: Ms2ger (~Ms2ger@91.181.135.207) (Ping timeout: 246 seconds)
1171. # [23:38] * Joins: sedovsek_ (~robert@93-103-90-17.dynamic.t-2.net)
1172. # [23:38] <TabAtkins> Add a doctype yourself.
1173. # [23:38] <karlcow> not really user friendly
1174. # [23:40] * Quits: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net)
1175. # [23:40] * sedovsek_ is now known as sedovsek
1176. # [23:40] * Quits: MacTed (~Thud@63.119.36.36)
1177. # [23:41] <eseidel2> TabAtkins: ok, so talk to me about testing
1178. # [23:42] <TabAtkins> ?_?
1179. # [23:42] <eseidel2> TabAtkins: do you know if we have any seamless tests? Or should I start writing? :)
1180. # [23:42] <TabAtkins> Since we don't have an impl, I doubt we ahve tests.
1181. # [23:42] <eseidel2> k
1182. # [23:42] <eseidel2> TabAtkins: well, thanks for your thoughts :)
1183. # [23:42] <TabAtkins> Welcome!
1184. # [23:45] * Quits: eseidel2 (~eseidel@173-164-128-209-SFBA.hfc.comcastbusiness.net) (Quit: eseidel2)
1185. # [23:45] * Quits: rniwa (rniwa@nat/google/x-kjdufyikfrjpfqmx) (Remote host closed the connection)
1186. # [23:47] * Joins: rniwa (rniwa@nat/google/x-itzvtbmelitwcquw)
1187. # [23:55] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Remote host closed the connection)
1188. # [23:57] * Quits: abarth_ (~abarth@2002:ada4:80d1:0:c5be:aabe:2932:5d4d) (Quit: abarth_)
1189. # [23:59] * Joins: jwalden (~waldo@c-71-202-165-226.hsd1.ca.comcast.net)
1190. # Session Close: Fri Mar 30 00:00:00 2012

The end :)