/irc-logs / freenode / #whatwg / 2009-10-21 / end

Options:

1. # Session Start: Wed Oct 21 00:00:00 2009
2. # Session Ident: #whatwg
3. # [00:01] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
4. # [00:03] * Joins: fishd_ (n=darin@nat/google/x-hceuytgqhwvzessl)
5. # [00:03] * Quits: annevk42 (n=annevk@c-c604e353.13-500-64736c15.cust.bredbandsbolaget.se)
6. # [00:09] * Joins: othermaciej_ (n=mjs@17.246.18.103)
7. # [00:10] * Quits: yatil (n=Adium@78.104.102.186) ("Leaving.")
8. # [00:10] * Joins: sylvaing (n=sylvaing@nat/microsoft/x-ptmixroskfjqpefb)
9. # [00:12] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
10. # [00:20] <roc> TabAtkins: sorry, my question was about the use of <angle> with radial gradients
11. # [00:20] <TabAtkins> roc: I'm sorry, I'm too dumb to answer questions today.
12. # [00:20] <roc> ok, I'll ask again tomorrow :-)
13. # [00:20] * TabAtkins pulls the email back up to answer it properly.
14. # [00:21] <roc> I've got linear gradients pretty much implemented, working on radial now
15. # [00:21] <TabAtkins> Okay, yes. I somehow skipped putting in the default value. It's 0.
16. # [00:22] <roc> ok, thanks
17. # [00:22] <TabAtkins> roc: If you want to be my hero, also do square/rectangle and diamond/rhombus radial gradients.
18. # [00:22] <TabAtkins> They're really really simple once you've got everything else done.
19. # [00:22] <roc> they're hard to implement actually
20. # [00:22] <roc> common graphics libraries don't support them directly
21. # [00:22] <TabAtkins> Really? It took me like 5 minutes to do them once I got circle and oval working.
22. # [00:23] <TabAtkins> Most of it was just trying to figure out the filledRectangle syntax.
23. # [00:23] <roc> we don't draw gradients with a lot of rectangles
24. # [00:23] <roc> we pass them down
25. # [00:24] <roc> to various native libraries
26. # [00:24] <TabAtkins> Ah, I see.
27. # [00:24] <TabAtkins> Damns.
28. # [00:24] * TabAtkins just started from the bottom.
29. # [00:24] <roc> I suppose we could approximate squares etc with linear gradients and clipping
30. # [00:24] <TabAtkins> Hmm, maybe that'll work.
31. # [00:25] <roc> you really want them implemented as close to the graphics hardware as possible, for performance
32. # [00:25] <roc> (gradients in general, I mean)
33. # [00:25] <TabAtkins> That won't help us solve the 7th gradient-shape I wanted, though - box (shape of the box, taking into account border-radius).
34. # [00:25] <TabAtkins> ;_;
35. # [00:26] * Quits: fishd_ (n=darin@nat/google/x-hceuytgqhwvzessl) (Read error: 60 (Operation timed out))
36. # [00:26] <TabAtkins> Though, to be honest, that's not as useful now that I don't skew the gradient.
37. # [00:26] <roc> we should define a new SVG Filter for that
38. # [00:26] <TabAtkins> I really just have no idea what can be done with SVG. I need to learn up on it.
39. # [00:26] * Quits: othermaciej (n=mjs@17.203.15.188) (Read error: 110 (Connection timed out))
40. # [00:26] * othermaciej_ is now known as othermaciej
41. # [00:27] <roc> actually
42. # [00:27] <roc> with feMorphology erode/dilate you can kind of approximate the effect
43. # [00:29] * Quits: othermaciej (n=mjs@17.246.18.103) (Remote closed the connection)
44. # [00:29] * Joins: othermaciej (n=mjs@17.203.15.188)
45. # [00:30] <roc> the only bit of heroism I'm considering is adding -moz-repeating-linear-gradient and -moz-repeating-radial-gradient, since they'd be really easy
46. # [00:30] <Philip`> Hixie: Gavin > Garrett
47. # [00:30] <TabAtkins> That's a long name, but sure. I still don't like the idea of other background properties leaking into image generation. Making it explicit is better.
48. # [00:31] <gavin> Philip`: ?
49. # [00:31] <Philip`> (alphabetically)
50. # [00:31] <Hixie> ooh
51. # [00:31] <Philip`> gavin: I think they're wrongly ordered in the credits section
52. # [00:31] <Hixie> alphabets are hard
53. # [00:32] * Quits: bgalbraith (n=bgalbrai@palm-64-28-152-140.palm.com)
54. # [00:32] <TabAtkins> roc: But I do like the idea behind repeating gradients, so I'd be happy to see them in there.
55. # [00:33] <TabAtkins> What would be the effect, though, of -moz-repeating-linear-gradient(red, blue)?
56. # [00:33] <TabAtkins> (Since, for a normal linear gradient, that defines a single sweep from red to blue across the entire height of the gradient.)
57. # [00:34] <TabAtkins> s/height of the gradient/height of the box/
58. # [00:34] <gavin> I'm in the credits?
59. # [00:34] <gavin> what for, I wonder
60. # [00:35] <gavin> oh, it's not me!
61. # [00:35] <Philip`> gavin: You're not the only person in the world called Gavin ;-)
62. # [00:35] <gavin> it's Gavin Carothers
63. # [00:35] <gavin> hate that guy
64. # [00:35] <Philip`> Because he stole your name?
65. # [00:36] <gavin> yeah
66. # [00:37] <Philip`> Good a reason as any to hate somebody
67. # [00:38] * Quits: jdouglas (n=jason@nat10.metaweb.com)
68. # [00:39] <TabAtkins> roc: Also, I assume that -moz-repeating-linear-gradient(red -10px, blue 50px) repeats with a 60px period?
69. # [00:39] * Joins: jdouglas (n=jason@nat11.metaweb.com)
70. # [00:39] <roc> yeah
71. # [00:40] <TabAtkins> Hmm. Is that equivalent to linear-gradient(red -10px, blue 50px, red 110px, blue 170px, ...)?
72. # [00:40] <roc> no
73. # [00:40] <TabAtkins> red -10px, blue 50px, red 50px, blue 110px?
74. # [00:40] <roc> it's equivalent to linear-gradient(red -10px, blue 50px, red 50px, blue 110px, ...)
75. # [00:40] <TabAtkins> k, yeah.
76. # [00:40] <TabAtkins> That makes better sense.
77. # [00:41] <roc> so you get an abrupt transition when the starting and ending colors are not the same
78. # [00:41] <TabAtkins> Yeah.
79. # [00:41] <roc> but I think that's OK, it's pretty obvious what to do to get a smooth transition there
80. # [00:41] <TabAtkins> Yeah, and I can put an example in the spec for it too.
81. # [00:41] <roc> and you might want the abrupt transition
82. # [00:42] * Joins: paul_irish (n=paul_iri@24.123.210.51)
83. # [00:43] <TabAtkins> I guess sure. Possibly more in radial - I dont' think I'd ever want it to be abrupt in linear. But there's no reason to prevent it.
84. # [00:49] * Joins: anoopb (n=chatzill@38.106.143.248)
85. # [00:49] * Parts: anoopb (n=chatzill@38.106.143.248)
86. # [01:02] <roc> TabAtkins: a couple more questions, if I may trouble you...
87. # [01:02] <TabAtkins> Go for it.
88. # [01:02] <roc> "In certain circumstances it is impossible to determine an appropriate ending-shape from the given parameters; in these instances the gradient image is just a solid color, defined by the last color-stop in the list. The following combinations of values will trigger this: closest-side if the starting-point is on a box edge, closest-corner if the starting-point is on a box corner, ellipse and closest-corner if the starting-point is on a box-edge,"
89. # [01:03] <roc> in those situations, the shape is simply a circle/ellipse with radius 0, isn't it?
90. # [01:03] <TabAtkins> Yes.
91. # [01:03] * Quits: jwalden (n=waldo@nat/mozilla/x-nuyxvmwplpshekyp) ("Reconnecting…")
92. # [01:03] <TabAtkins> Which is also "a solid color, defined by the last color-stop in the list".
93. # [01:03] <roc> ok, I suggest you rephrase "it is impossible to determine an appropriate ending-shape" then
94. # [01:03] <TabAtkins> Hmm, okay.
95. # [01:03] <roc> there' nothing really inappropriate about an empty circle or ellipse
96. # [01:04] <TabAtkins> Well, it's sort of a degenerate circle.
97. # [01:04] * Joins: ojan (n=ojan@72.14.229.81)
98. # [01:04] <TabAtkins> Equivalent to a point.
99. # [01:04] <roc> yeah
100. # [01:04] * Quits: gsnedders (n=gsnedder@c83-252-237-97.bredband.comhem.se)
101. # [01:04] <TabAtkins> Depending on who you're talking to, degenerate shapes aren't valid. ^_^ I'll rephrase it, though.
102. # [01:04] <roc> "and finally ellipse and either closest-corner or closest-side if the starting-point is outside of the box."
103. # [01:05] <roc> I don't think we need to call out degenerate shapes in the spec, unless the spec demands behavior for the degenerate shape that is different from what you would get applying the normal rules
104. # [01:06] <TabAtkins> That last one really is an error, though. There's no way to determine the dimensions of the ellipse in that case.
105. # [01:07] <roc> there is
106. # [01:07] <roc> suppose I'm using closest-side
107. # [01:07] <TabAtkins> Unless you extend the lines defined by the sides outside of the box, I guess.
108. # [01:07] <roc> right
109. # [01:07] * Quits: paul_irish (n=paul_iri@24.123.210.51) (Remote closed the connection)
110. # [01:07] <TabAtkins> You can attempt to infer that, but I don't say anything that would make that required.
111. # [01:07] <roc> I dunno if it's useful
112. # [01:07] <roc> but it's what my code does
113. # [01:08] <roc> I'll have to add extra code to detect the outside-box case to match the spec as written
114. # [01:08] <TabAtkins> Yeah, I had to do so as well (my code didn't gracefully handle it, so it was required anyway).
115. # [01:08] * Joins: anoopb (n=chatzill@38.106.143.248)
116. # [01:09] <roc> so I suggest changing the spec to make that the behaiour
117. # [01:09] <anoopb> any recommendations for tutorials/demos of the canvas element and images?
118. # [01:09] <TabAtkins> Hm, k. I'll see if I can do so gracefully.
119. # [01:09] <anoopb> more specifically, i'm looking for effects.
120. # [01:10] <roc> I think it probably would be useful, e.g. it means you could animate the movement of an ellipse into the box by animating the start position
121. # [01:10] <roc> oh wait, that wouldn't work
122. # [01:10] <roc> so I dunno :-)
123. # [01:10] <TabAtkins> Nah, it'll collapse to a line as it crosses the box-edge. ^_^
124. # [01:12] <TabAtkins> I mean, you could still use it when it was outside of the box. You'd have to use color-stop positions greater than 100%, but still.
125. # [01:12] * Joins: paul_irish (n=paul_iri@rrcs-24-123-210-51.central.biz.rr.com)
126. # [01:12] <TabAtkins> I just figured using farthest-side/farthest-corner was equally useful.
127. # [01:19] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
128. # [01:19] <TabAtkins> roc: Doing the animated ellipse thing would be doable relatively easily with an explicitly sized SVG gradient, and animating the background-position.
129. # [01:20] <roc> yeah
130. # [01:20] <deltab> anoopb: https://developer.mozilla.org/en/Canvas_tutorial
131. # [01:20] <deltab> anoopb: effects?
132. # [01:21] <TabAtkins> roc: I'm heading out to do some yardwork, but I'll stay in the channel and be back later. If you have any more questions, just ask.
133. # [01:21] <roc> sure, thanks a ton
134. # [01:22] <anoopb> deltab: i didn't mean effects. I wanted to be able to do some neat things like expand the image in focus while shrinking others to maintain the bounds of the canvas
135. # [01:22] * Joins: MikeSmith (n=MikeSmit@EM114-48-132-10.pool.e-mobile.ne.jp)
136. # [01:23] <deltab> transformations? https://developer.mozilla.org/en/Canvas_tutorial/Transformations
137. # [01:24] * Joins: jwalden (n=waldo@nat/mozilla/x-hkbtzbncdoaujsgp)
138. # [01:26] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
139. # [01:28] <anoopb> deltab: that's it. thank you.
140. # [01:29] * Quits: othermaciej (n=mjs@17.203.15.188) (Read error: 104 (Connection reset by peer))
141. # [01:29] * Joins: othermaciej (n=mjs@17.203.15.188)
142. # [01:29] * Quits: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
143. # [01:31] * Joins: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
144. # [01:32] * Quits: jdouglas (n=jason@nat11.metaweb.com)
145. # [01:34] * Joins: jdouglas (n=jason@nat11.metaweb.com)
146. # [01:34] * Quits: jdouglas (n=jason@nat11.metaweb.com) (Remote closed the connection)
147. # [01:34] * Joins: jdouglas (n=jason@nat08.metaweb.com)
148. # [01:40] * Quits: paul_irish (n=paul_iri@rrcs-24-123-210-51.central.biz.rr.com) (Remote closed the connection)
149. # [01:43] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) ("Wünsche weiterhin guten Flug")
150. # [01:50] * Quits: gunderwonder (n=gunderwo@84.49.178.140)
151. # [01:58] <TabAtkins> roc: Here's an interesting question. I say that the "box" referred to throughout the rules is simply a rectangle the same size as an SVG image without intrinsic dimensions (in background situations, that's the size of the background bounding-box). However, once that's calculated, it doesn't change. If you used background-position to *move* the gradient image, it shouldn't adjust to the...
152. # [01:58] <TabAtkins> ...new box edges, right?
153. # [01:58] <roc> no
154. # [01:58] <roc> it shouldn't
155. # [01:59] <roc> I should write a test for that but I'm pretty we'll do that right
156. # [01:59] * Joins: paul_irish (n=paul_iri@rrcs-24-123-210-51.central.biz.rr.com)
157. # [01:59] <TabAtkins> Frex, radial-gradient(ellipse farthest-side, red, blue) should create a gradient that turns blue *right* at the box edges. But if I then do background-position: 100px top (in a 200px wide box) it'll instead look like a half-ellipse, correct?
158. # [02:00] <TabAtkins> One that starts on the right side and turns blue halfway through the box.
159. # [02:03] * Joins: nessy (n=Adium@203-158-45-196.dyn.iinet.net.au)
160. # [02:04] <roc> yes
161. # [02:04] * Joins: yutak_home (n=kee@61.117.6.79)
162. # [02:12] * Quits: paul_irish (n=paul_iri@rrcs-24-123-210-51.central.biz.rr.com) (Remote closed the connection)
163. # [02:30] <othermaciej> hey all
164. # [02:31] * Joins: slightlyoff (n=slightly@72.14.229.81)
165. # [02:32] <othermaciej> is anyone around who is familiar with the html5 spec production toolchain, and perhaps willing to volunteer to enhance it?
166. # [02:38] <TabAtkins> That'd be philip and/or gsnedders, right?
167. # [02:41] * Joins: wakaba_ (n=wakaba_@122.221.184.68)
168. # [02:43] <othermaciej> I don't actually know anything about the mechanics
169. # [02:43] <othermaciej> I know jgraham has done something with it as well (adding the issue markers)
170. # [02:44] <othermaciej> specifically I wanted to get someone to make the change to add spec diff links to bugzilla bugs based on commit messages
171. # [02:47] * Quits: dglazkov (n=dglazkov@nat/google/x-llvydowgewiktdej)
172. # [02:47] * Quits: yutak_home (n=kee@61.117.6.79) ("Ex-Chat")
173. # [02:48] * Quits: ap (n=ap@17.246.19.174)
174. # [02:49] * Joins: paul_irish (n=paul_iri@12.182.97.2)
175. # [02:57] * Quits: cying_ (n=cying@70.90.171.153)
176. # [03:02] * Joins: miketaylr (n=miketayl@24.42.95.234)
177. # [03:03] * Quits: miketaylr (n=miketayl@24.42.95.234) (Client Quit)
178. # [03:03] * Joins: miketaylr (n=miketayl@24.42.95.234)
179. # [03:07] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
180. # [03:15] * Quits: MikeSmith (n=MikeSmit@EM114-48-132-10.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
181. # [03:22] * Parts: ojan (n=ojan@72.14.229.81)
182. # [03:22] * Quits: dave_levin (n=dave_lev@74.125.59.65)
183. # [03:24] * Quits: dimich (n=dimich@74.125.59.73)
184. # [03:25] * Joins: svtech (n=stanv@83.228.56.37)
185. # [03:30] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
186. # [03:30] * Quits: sylvaing (n=sylvaing@nat/microsoft/x-ptmixroskfjqpefb) (Read error: 110 (Connection timed out))
187. # [03:34] * Joins: sylvaing (n=sylvaing@72.62.126.171)
188. # [03:43] * Quits: weinig (n=weinig@17.246.17.253)
189. # [03:53] <roc> TabAtkins: for radial gradients, does <shape> default to 'circle' and <size> default to 'closest-side'?
190. # [03:53] <roc> oh wait
191. # [03:54] <roc> <size> defaults to cover, with mean farthest-corner, ok. I still don't see the default for <shape>
192. # [03:57] * Joins: dglazkov (n=dglazkov@67.188.0.62)
193. # [03:57] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
194. # [03:57] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
195. # [04:05] * Quits: dglazkov (n=dglazkov@67.188.0.62) (Read error: 145 (Connection timed out))
196. # [04:05] * dglazkov_ is now known as dglazkov
197. # [04:06] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
198. # [04:06] * Quits: jdouglas (n=jason@nat08.metaweb.com)
199. # [04:07] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
200. # [04:07] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
201. # [04:10] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
202. # [04:11] * Joins: fishd_ (n=darin@67.180.164.209)
203. # [04:12] * Joins: fishd__ (n=darin@72.14.224.1)
204. # [04:13] * Quits: sylvaing (n=sylvaing@72.62.126.171) (Read error: 145 (Connection timed out))
205. # [04:16] * Quits: pmuellr (n=pmuellr@69.61.162.35)
206. # [04:19] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
207. # [04:20] * Quits: fishd_ (n=darin@67.180.164.209) (Read error: 145 (Connection timed out))
208. # [04:29] * Joins: dglazkov_ (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
209. # [04:31] * Quits: erlehmann (n=erlehman@82.113.106.0) (Read error: 110 (Connection timed out))
210. # [04:39] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
211. # [04:46] * Joins: yatil (n=Adium@78.104.102.186)
212. # [04:48] * Joins: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
213. # [04:49] * Quits: bgalbraith (n=bgalbrai@71.202.109.116)
214. # [04:49] * Quits: dglazkov (n=dglazkov@72.14.224.1) (Read error: 110 (Connection timed out))
215. # [04:49] * dglazkov_ is now known as dglazkov
216. # [04:58] * Joins: jdouglas (n=jason@c-76-126-175-30.hsd1.ca.comcast.net)
217. # [05:26] * Quits: jwalden (n=waldo@nat/mozilla/x-hkbtzbncdoaujsgp) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.1.3/20090909051541]")
218. # [05:31] * Quits: yatil (n=Adium@78.104.102.186) ("Leaving.")
219. # [05:31] * Quits: slightlyoff (n=slightly@72.14.229.81) (Read error: 110 (Connection timed out))
220. # [05:35] * lmorchard is now known as lmorchard|away
221. # [05:52] * Quits: othermaciej (n=mjs@17.203.15.188)
222. # [06:03] * Quits: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
223. # [06:07] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
224. # [06:24] * Quits: miketaylr (n=miketayl@24.42.95.234)
225. # [06:46] <TabAtkins> roc: Dangit, how did I forget that one too? It defaults to ellipse.
226. # [06:46] <roc> ok, thanks
227. # [06:51] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
228. # [06:52] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
229. # [06:54] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
230. # [06:56] * Quits: svtech (n=stanv@83.228.56.37)
231. # [07:00] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
232. # [07:00] * Joins: erlehmann (n=erlehman@82.113.121.17)
233. # [07:02] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
234. # [07:04] <TabAtkins> roc, I'm making edits to the draft on my personal site now. I think you were ok with linear-gradient being 'invalid' if it points in the wrong direction, right? But you wanted the final 'invalid' radial-gradient case to be valid?
235. # [07:04] * Quits: aaron (n=drunknba@cpe-76-173-195-145.socal.res.rr.com)
236. # [07:05] <roc> TabAtkins: actually in my implementation it was simplest to not make linear-gradient invalid
237. # [07:05] <roc> we pick the destination corner based entirely on the angle
238. # [07:06] <TabAtkins> Hmm. What happens with -10px -10px 180deg, then?
239. # [07:06] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
240. # [07:06] <roc> the destination corner is the top-right corner
241. # [07:07] <TabAtkins> Really? How do you figure? 180deg points to the left.
242. # [07:07] <roc> oh sorry, it's the opposite corner, right
243. # [07:08] <roc> bottom left
244. # [07:08] * Joins: drunknbass (n=drunknba@cpe-76-173-195-145.socal.res.rr.com)
245. # [07:08] <roc> then we find the point that is the intersection of the gradient line with the line that passes through the bottom-left corner and is perpendicular to the gradient line
246. # [07:08] <roc> that's the gradient line end point
247. # [07:09] <roc> you can always follow the instructions in your draft, and it will give you a unique point
248. # [07:09] <TabAtkins> Ah, k. So you're okay with the direction getting flipped in degenerate cases like that.
249. # [07:09] <roc> yeah
250. # [07:09] <TabAtkins> k.
251. # [07:09] <roc> it would be extra code to detect that case and do something special
252. # [07:10] * Quits: drunknbass (n=drunknba@cpe-76-173-195-145.socal.res.rr.com) (Client Quit)
253. # [07:10] * Joins: drunknbass (n=drunknba@cpe-76-173-195-145.socal.res.rr.com)
254. # [07:11] <TabAtkins> No problem. I don't have a particular preference on that; I just chose what felt like a reasonable behavior.
255. # [07:13] <roc> I've got radial gradients all working now, but writing the automated tests for gradients sucks :-(
256. # [07:15] <TabAtkins> Yeah, I'm sure.
257. # [07:15] <TabAtkins> Thanks for implementing it all, though! Woo!
258. # [07:22] * Joins: gunderwonder (n=gunderwo@140.84-49-178.nextgentel.com)
259. # [07:23] <TabAtkins> roc: I'm willing to spec repeating-linear-gradient and repeating-radial-gradient. The only difference is that the color-stops repeat infinitely in both directions, +/- multiples of the distance between the first and last stop, right?
260. # [07:24] <roc> right
261. # [07:24] <roc> you need to define the rendering when stops all coincide
262. # [07:25] <TabAtkins> Hmm? You mean when you have linear-gradient(red 50px, blue 50px)?
263. # [07:25] <roc> yeah
264. # [07:25] <roc> actually
265. # [07:26] <roc> yeah
266. # [07:26] <roc> :-)
267. # [07:26] <TabAtkins> That should be already defined. Before the first color-stop it's red, and after the last it's blue.
268. # [07:26] <roc> I mean repeating-linear-gradient(red 50px, blue 50px)
269. # [07:26] <TabAtkins> Oh! Um.
270. # [07:27] <TabAtkins> I'll just say it's purple. ^_^
271. # [07:27] <TabAtkins> Do you have anything in mind to do yet? There's no 'right' behavior here - anything I spec will be essentially arbitrary.
272. # [07:29] <TabAtkins> Actually, I'll probably just be consistent with the other failure modes and say it's blue.
273. # [07:30] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
274. # [07:31] * Joins: svtech (n=stanv@83.228.56.37)
275. # [07:32] <TabAtkins> k, all the changes are made except for the 'invalid' linear-gradient case. I'm still trying to figure out an elegant way to say that.
276. # [07:33] <roc> yeah, I'd say "blue"
277. # [07:39] * TabAtkins will try very hard not to actually say "blue" when he writes it up.
278. # [07:45] * Joins: TabAtkins_ (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
279. # [07:46] * Quits: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Read error: 104 (Connection reset by peer))
280. # [07:46] * TabAtkins_ is now known as TabAtkins
281. # [07:50] * Quits: gunderwonder (n=gunderwo@140.84-49-178.nextgentel.com)
282. # [07:51] * Joins: slightlyoff (n=slightly@204.14.154.228)
283. # [07:52] * Joins: slightlyoff_ (n=slightly@72.14.224.1)
284. # [07:55] * Quits: slightlyoff (n=slightly@204.14.154.228) (Read error: 60 (Operation timed out))
285. # [07:55] * slightlyoff_ is now known as slightlyoff
286. # [07:55] * yutak_ is now known as yutak
287. # [07:56] * Joins: annevk42 (n=annevk@c-c604e353.13-500-64736c15.cust.bredbandsbolaget.se)
288. # [08:00] * Joins: fishd_ (n=darin@c-67-180-164-209.hsd1.ca.comcast.net)
289. # [08:04] * Joins: Tim_ (n=ttepas--@p5B014C76.dip.t-dialin.net)
290. # [08:08] * Joins: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
291. # [08:13] * Joins: fishd (n=darin@216.239.45.130)
292. # [08:18] * Quits: fishd__ (n=darin@72.14.224.1) (Read error: 110 (Connection timed out))
293. # [08:20] * Joins: zalan (n=zalan@catv-89-135-144-122.catv.broadband.hu)
294. # [08:22] * Quits: erlehmann (n=erlehman@82.113.121.17) (Read error: 113 (No route to host))
295. # [08:24] * Quits: ttepass- (n=ttepas--@p5B014821.dip.t-dialin.net) (Read error: 110 (Connection timed out))
296. # [08:24] * Joins: zcorpan (n=zcorpan@83.252.193.59)
297. # [08:24] * Quits: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 110 (Connection timed out))
298. # [08:25] <zcorpan> good morning
299. # [08:25] <annevk42> morning
300. # [08:25] * annevk42 is still somewhat asleep
301. # [08:31] * Quits: fishd_ (n=darin@c-67-180-164-209.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
302. # [08:35] <zcorpan> Philip`: any progress yet? :)
303. # [08:41] <zcorpan> Hixie: should nextid and rb get the isindex treatment wrt HTMLUnknownElement?
304. # [08:42] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
305. # [08:42] <Hixie> hm?
306. # [08:42] <zcorpan> i'm pretty sure <nextid> is an HTMLUnknownElement in browsers
307. # [08:42] <Hixie> ah
308. # [08:42] <Hixie> file a bug
309. # [08:42] <Hixie> :-)
310. # [08:43] * Hixie is trying to figure out why prince doesn't seem to support <style> in SVG
311. # [08:43] <zcorpan> i'll check all obsolete elements to see if there are more
312. # [08:43] <Hixie> cool, thanks
313. # [08:43] * Joins: ttepass- (n=ttepas--@p5B013DD1.dip.t-dialin.net)
314. # [08:49] * annevk42 wonders what <a methods> did
315. # [08:50] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
316. # [08:50] <annevk42> hmm, weird
317. # [08:51] * Joins: ttepasse (n=ttepas--@p5B013979.dip.t-dialin.net)
318. # [08:53] <othermaciej> <a methods>?
319. # [08:55] <zcorpan> html2?
320. # [08:57] <annevk42> http://www.utoronto.ca/web/HTMLdocs/NewHTML/a_methods.html
321. # [08:59] <annevk42> looks like it might be for non-browser UAs though the search icon remark suggests otherwise
322. # [08:59] * annevk42 doesn't really get the design
323. # [09:00] <othermaciej> maybe the idea was that the browser would let you choose what method to use to dereference the link?
324. # [09:01] <Hixie> <a methods> is just like <a urn> and <head profile>
325. # [09:01] <Hixie> nonsensical solution to a non-problem
326. # [09:02] <othermaciej> I have no idea what <a urn> is either
327. # [09:02] <othermaciej> man, every time I think I have heard of everything that was ever in HTML, something new surprises me
328. # [09:02] * Joins: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net)
329. # [09:04] <othermaciej> I love what the HTML 2.0 spec says: "The syntax and semantics of the URN attribute are not yet specified."
330. # [09:04] <othermaciej> rare moment of honesty!
331. # [09:04] * Quits: Tim_ (n=ttepas--@p5B014C76.dip.t-dialin.net) (Read error: 110 (Connection timed out))
332. # [09:04] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
333. # [09:05] * Quits: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com) (Read error: 104 (Connection reset by peer))
334. # [09:05] * Joins: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
335. # [09:06] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
336. # [09:07] <zcorpan> anyone have ie8 around?
337. # [09:07] <Hixie> .sure
338. # [09:07] <zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/283
339. # [09:07] <Hixie> othermaciej: are recent bugs what you had in mind?
340. # [09:08] <othermaciej> Hixie: yes, thank you very much sir
341. # [09:09] <Hixie> cool
342. # [09:09] <zcorpan> do we have to mark bugs as closed?
343. # [09:09] <Hixie> zcorpan: i got an error
344. # [09:09] <Hixie> looks like IE broke the link
345. # [09:09] <Hixie> can you upload it?
346. # [09:10] <othermaciej> zcorpan: if you don't it will get marked as "no reply from commenter" eventually, so depends on whether you care about that
347. # [09:10] <zcorpan> Hixie: done
348. # [09:10] * Philip` still thinks Hixie should add the header that disables IE XSS protection on the Live DOM Viewer
349. # [09:10] <zcorpan> othermaciej: ok
350. # [09:11] <Hixie> zcorpan: got another error
351. # [09:11] <Hixie> Philip`: i refuse to add a non-standard header whose purpose it is to tell the browser to follow the spec
352. # [09:11] <zcorpan> Hixie: error about <applet>? or other?
353. # [09:11] <zcorpan> Hixie: (you can change the prefs in ie to disable the xss protection)
354. # [09:11] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
355. # [09:12] <Hixie> zcorpan: Object doesn't support this property or method on line 30
356. # [09:12] <othermaciej> zcorpan: once we're actually in Last Call, it's probably good to do so, because our Disposition of Comments will look suspicious if all of them indicate no reply and there aren't any "agree" responses
357. # [09:12] * Quits: ttepass- (n=ttepas--@p5B013DD1.dip.t-dialin.net) (Read error: 110 (Connection timed out))
358. # [09:12] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
359. # [09:13] <zcorpan> maybe i can batch-close my bugs at some point
360. # [09:18] <zcorpan> anyone got an opinion on whether <spacer> should be HTMLElement or HTMLUnknownElement?
361. # [09:18] <ttepasse> Hey, HTML 3.0 ditches <a urn> but has instead <html urn="...">
362. # [09:19] <zcorpan> why is spacer a void element in the html5 parser?
363. # [09:19] * Joins: yatil (n=Adium@78.104.102.186)
364. # [09:20] <zcorpan> it's void and HTMLSpacerElement in gecko but a normal unknown element in webkit, opera and ie, afaict
365. # [09:20] * Parts: svtech (n=stanv@83.228.56.37)
366. # [09:20] <annevk42> yeah
367. # [09:21] <othermaciej> I had no idea <spacer> existed
368. # [09:21] <annevk42> could remove that quirk
369. # [09:21] <othermaciej> we don't do anything special for it afaik
370. # [09:21] <annevk42> Safari on Mac doesn't afaict
371. # [09:21] <annevk42> nor Chrome
372. # [09:22] * Joins: cedricv (n=cedric@112.199.133.135)
373. # [09:25] * Quits: fishd (n=darin@216.239.45.130) (Read error: 60 (Operation timed out))
374. # [09:25] <zcorpan> ok filed bugs
375. # [09:25] <Hixie> thanks
376. # [09:27] <zcorpan> ie7 has the form margin in standards mode too (like opera)
377. # [09:27] <ttepasse> zcorpan, in Netscape 3 <spacer> was a void element. Says this tutorial from 1998.
378. # [09:33] * Quits: roc (n=roc@203.97.204.82)
379. # [09:43] <zcorpan> "Inserting a form on a page would often break the pixel-perfect design by pushing things around. That was caused by the form’s margins, but I didn’t know that. So to prevent this I used to insert the form’s start and end tags between table rows." - http://www.456bereastreet.com/archive/200511/reveal_your_old_school_web_development_hacks/
380. # [09:49] * othermaciej facepalms
381. # [09:51] <zcorpan> i think we should just change the parser to not foster parent forms
382. # [09:52] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
383. # [09:53] * Quits: jdouglas (n=jason@c-76-126-175-30.hsd1.ca.comcast.net)
384. # [09:53] <Dashiva> Having per-row forms would be useful for many things
385. # [09:54] <zcorpan> Dashiva: form="" handles that
386. # [09:55] <Dashiva> Yeah, but that leads to really silly markup
387. # [09:55] <Dashiva> A hundred empty form tags outside the table
388. # [09:55] * Joins: gsnedders (n=gsnedder@c83-252-234-3.bredband.comhem.se)
389. # [09:55] <zcorpan> they don't have to be outside the table
390. # [09:55] <zcorpan> can be in the first cell
391. # [09:55] <Dashiva> True
392. # [09:55] <zcorpan> of the relevant row
393. # [09:55] <Dashiva> Didn't think of that
394. # [09:56] <zcorpan> i agree though that it'd be nice to support forms in tables as if they were <tbody>, but Hixie didn't want to experiment with it and it'd probably break things anyway
395. # [09:57] * Quits: slightlyoff (n=slightly@72.14.224.1)
396. # [10:02] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
397. # [10:04] * Parts: annevk42 (n=annevk@c-c604e353.13-500-64736c15.cust.bredbandsbolaget.se)
398. # [10:04] <zcorpan> Hixie: should we have <link rel=author> too, mapping to atom <author><uri>?
399. # [10:04] <Hixie> no way to map it to a name
400. # [10:05] <zcorpan> you get the name from <meta name=author>
401. # [10:06] <Hixie> but how do you know which rel=author maps to which name=author?
402. # [10:07] <zcorpan> ah... i thought you'd only have one
403. # [10:12] * Quits: foolip (n=philip@h-63-95.A163.priv.bahnhof.se) ("Ex-Chat")
404. # [10:16] * Quits: hober (n=ted@unaffiliated/hober) (Remote closed the connection)
405. # [10:19] <annevk> you could map it based on the title attribute
406. # [10:19] <annevk> if you specify that for rel=author the title attribute gives the name
407. # [10:19] <annevk> and that for name=author content gives the name
408. # [10:20] <annevk> not sure you'd need <meta name=author> in that case though
409. # [10:20] * Joins: a-ja (n=a-ja@70.230.156.76)
410. # [10:21] <Hixie> so <link rel=author href="http://ln.hixie.ch/" title="Hixie's Natural Log"> would be invalid?
411. # [10:22] <annevk> yes
412. # [10:22] <annevk> prolly not ideal
413. # [10:22] <Hixie> annevk: what's the latest ED of MQ? http://www.w3.org/TR/css3-mediaqueries/ is more recent than http://dev.w3.org/csswg/css3-mediaqueries/
414. # [10:23] <annevk> it's more recent because I made all the edits way in advance and Bert did the WD version in private
415. # [10:23] <annevk> with "way in advance" I mean that publication was "way delayed"
416. # [10:24] <Hixie> so what should i reference? the TR which will become out of date, or the ED which is out of date?
417. # [10:24] <annevk> how is the ED out of date?
418. # [10:25] <hsivonen> I guess MS has problems getting people to install Silverlight. Now Flip4Mac is used as a Silverlight delivery device.
419. # [10:30] * Joins: gunderwonder (n=gunderwo@garage.upstruct.com)
420. # [10:32] <Hixie> annevk: it's august
421. # [10:32] <Hixie> annevk: TR is sept
422. # [10:33] * Quits: a-ja (n=a-ja@70.230.156.76) (Remote closed the connection)
423. # [10:33] <Hixie> oh i see
424. # [10:33] <Hixie> you mean it's the same version
425. # [10:33] <Hixie> just different date
426. # [10:33] <annevk> yes
427. # [10:33] <Hixie> ok
428. # [10:34] <Hixie> thanks
429. # [10:35] <Hixie> othermaciej: when i mark a bug as NEEDSINFO because I simply don't understand the request, should I be giving the Rejected boilerplate, or can i just mark it NEEDSINFO without the boilerplate?
430. # [10:36] <othermaciej> Hixie: I think it would be good to have the boilerplate, but maybe there should be a version specifically for NEEDSINFO bugs that highlights the need to provide the requested info
431. # [10:37] <othermaciej> Hixie: specifically, I wouldn't want someone to complain that they didn't know they had to take action on their NEEDSINFO bug to have it actually addressed
432. # [10:38] <Hixie> k. i'll use rejected until further notice then.
433. # [10:38] * Joins: michaelforrest (n=michaelf@91.189.88.12)
434. # [10:39] <zcorpan> will we see the boilerplate over and over in the same bug when it's reopened and NEEDSINFOed back and forth?
435. # [10:39] <zcorpan> or just the first time it's NEEDSINFOed
436. # [10:41] <Dashiva> Maybe just a link to the process
437. # [10:41] <Hixie> othermaciej: is http://www.w3.org/Bugs/Public/show_bug.cgi?id=7923#c1 ok?
438. # [10:41] <othermaciej> Hixie: works4me
439. # [10:41] <Hixie> k
440. # [10:42] <othermaciej> zcorpan: yeah, I don't think it's necessary to repeat the whole thing over and over - though hopefully it's rare for that to happen at all
441. # [10:42] <annevk> the contributor@whatwg.org bugs prolly deserve special status anyway
442. # [10:42] <zcorpan> othermaciej: it has happened a couple of times
443. # [10:43] <jgraham> I guess in most cases the original commenter never sees the replies to thoise bugs
444. # [10:43] <annevk> cause unless the person that files them keeps track it's unlikely the person will close it
445. # [10:43] <othermaciej> yeah
446. # [10:43] <othermaciej> they're highly likely to end up in the NoReply pile
447. # [10:43] <zcorpan> would be nice if the comment box would hook into the annotation login system and add the email to cc
448. # [10:44] <annevk> only registered emails can be on the cc
449. # [10:44] <zcorpan> oh well
450. # [10:45] <jgraham> It would be nice if you could add your email address to the comment box anyway
451. # [10:45] <jgraham> Or at least if it gave you a link to the bug page (an actual link not just an alert)
452. # [10:45] <Hixie> you can just copy and paste the link from the alert
453. # [10:46] <Hixie> anyway, patches welcome, so long as it doesn't make the UI any more complicated
454. # [10:46] * Joins: mat_t (n=mattomas@91.189.88.12)
455. # [10:46] <jgraham> Hixie: That's significantly more work
456. # [10:46] * Joins: a-ja (n=a-ja@70.230.156.76)
457. # [10:46] * Parts: a-ja (n=a-ja@70.230.156.76)
458. # [10:46] <jgraham> (one middle click on a link vs select text + copy + open new tab + paste + press return)
459. # [10:46] <zcorpan> Hixie: is a line above the comment box showing status/link instead of alert more comlicated UI?
460. # [10:47] <Hixie> zcorpan: that might work
461. # [10:49] * hsivonen wonders how many names with capital letters X3D has
462. # [10:49] * Joins: ROBOd (n=robod@89.122.216.38)
463. # [10:49] * hsivonen wonders what the level of browser vendor interest in X3D as Part of the Platform is
464. # [10:50] <Philip`> hsivonen: All of them have capitals
465. # [10:50] <hsivonen> Philip`: how many is "All"?
466. # [10:52] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
467. # [10:52] <Philip`> hsivonen: Zillions
468. # [10:52] <Philip`> (approximately)
469. # [10:52] <Philip`> http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19776-1.2-X3DEncodings-XML/Part01/Schema.html
470. # [10:53] <Hixie> othermaciej: what is "auto-click" in the safari bookmark manager?
471. # [10:53] <othermaciej> Hixie: the worst name for a feature ever
472. # [10:53] <othermaciej> Hixie: but what it does is...
473. # [10:53] <Philip`> (http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19776-1.2-X3DEncodings-XML/Part01/examples.html#SimpleExample has specific examples)
474. # [10:54] <othermaciej> if you check that box that for a bookmark folder, then selecting that folder will open its contents in tabs (one tab per bookmark)
475. # [10:54] <hsivonen> Philip`: the use of XSD doesn't make a good first impression
476. # [10:55] <Hixie> othermaciej: ...i see
477. # [10:55] <othermaciej> hsivonen: I'm curious how X3D compares to Google's O3D (which I gather is now built in to Chrome but not yet proposed for standardization afaik)
478. # [10:55] <othermaciej> Hixie: it's a useful feature - just very badly named for reasons I can't get into here
479. # [10:55] <hsivonen> I don't think I'm putting X3D in the parser for plug-ins. And I'm not seeing any interest in shipping a native X3D impl. in Gecko.
480. # [10:55] <Philip`> hsivonen: I expect they didn't have any realistic choices other than DTD and XSD when writing the spec (several years ago)
481. # [10:56] * jgraham hoped that autoclick would cause random and unexpected click events to be dispatched all over the screen
482. # [10:56] <Hixie> othermaciej: the only thing i use bookmarks for is bookmarklets, so not useful for me, but i can see it might be useful :-)
483. # [10:56] <Philip`> othermaciej: They seem totally different, since X3D is declarative and O3D is imperative
484. # [10:56] <jgraham> It would be like the days when Yahoo had the "take me to a random site" feature
485. # [10:57] <othermaciej> Philip`: but both are based on a retained scene graph model
486. # [10:57] <hsivonen> othermaciej: do you mean Google is putting O3D into Chrome even though Gecko and WebKit have this WebGL thing going?
487. # [10:57] <othermaciej> (unlike WebGL which is immediate mode)
488. # [10:57] <othermaciej> hsivonen: well, Google is also putting WebGL into Chrome
489. # [10:58] <othermaciej> O3D is different from WebGL - it's retained mode, so a bit more like Opera's old 3D canvas experiment, or like X3D (not sure if it has a serialized markup form though)
490. # [10:58] <hsivonen> so we are headed towards 3 out of 5 supporting WebGL, 1 out of 5 supporting O3D and 0 out of 5 supporting X3D?
491. # [10:58] <othermaciej> Google is also shipping Native Client built in (I believe you can now start a Worker that loads and runs x86 native code)
492. # [10:59] <othermaciej> I believe Opera is in the Khronos subgroup that is working on WebGL but I'm not 100% sure
493. # [10:59] <hsivonen> does built-in mean that O3D and Native Client aren't in the NPAPI prison?
494. # [10:59] <annevk> we are
495. # [10:59] <othermaciej> I suspect Microsoft will never ever implement it because Mozilla chose to do it at Khronos, a standards body that Microsoft will never join in a million years
496. # [10:59] <Philip`> othermaciej: Hmm, I suppose the retainedness thing is true, though O3D seems to be more of a low-level render graph while X3D is a higher-level thing
497. # [10:59] <Dashiva> Why not?
498. # [10:59] <annevk> not sure if our old 3D stuff was retained, but it was definitely higher-level
499. # [11:00] <othermaciej> hsivonen: I believe that is the case for NaCl, at least that was their plan
500. # [11:00] <hsivonen> othermaciej: I see
501. # [11:00] <Philip`> X3D also has support for interactivity (routing messages between objects, optionally with scripts and stuff), whereas O3D presumably leaves it all to JS
502. # [11:00] <othermaciej> I'm kind of concerned about pushing x86 native code into the Web platform, even if supposedly safely sandboxed
503. # [11:00] <annevk> as long as they ensure it can be implemented on top of DirectX Microsoft can probably do it
504. # [11:00] <hsivonen> I hope we don't end up in a situation where all devices have to support i386 instructions for Web compat
505. # [11:01] <annevk> othermaciej, last I heard they had not specced the details of sandboxing
506. # [11:02] <hsivonen> even if Google manages to badger people into publishing x86, x86_64 and arm code, it would we a huge barrier for entry for novel CPU architectures
507. # [11:02] <othermaciej> I asked some Chrome folks about this and they said the solution was to let Web sites post native code binaries for whatever architectures they cared to, and eventually they'd port Native Client to support some other architectures that they care about
508. # [11:02] <othermaciej> that or some server component would translate to different native instruction sets on the fly
509. # [11:02] <Philip`> I thought the idea was to emulate x86 on other CPUs, but that seems to be missing the performance aspect
510. # [11:02] <annevk> othermaciej, ouch
511. # [11:03] <Philip`> (and performance seems to be largely the point of native code)
512. # [11:03] <othermaciej> any of these approaches seems pretty detrimental to innovation in CPU arhictectures
513. # [11:03] <hsivonen> it would suck big time if Native Client was already established enough to require iPhone and N900 to support x86 instructions
514. # [11:03] <Philip`> Intel ought to be promoting NaCl
515. # [11:03] <othermaciej> anyway, yeah, no formal spec, not proposed as a standard, only barely less terrible for the Web than ActiveX, and now available in Chrome
516. # [11:04] <annevk> hopefully they don't become market leader
517. # [11:04] <Dashiva> The people saying "Google is becoming Microsoft" must feel vindicated
518. # [11:05] <Philip`> Is Google planning to support all these features backward-compatibly in Chrome forever?
519. # [11:05] <hsivonen> I think disrespecting JS as a language and treating it as a mere GWT compile target is way better than sending x86 code down the wire
520. # [11:05] <othermaciej> the IE team seems more hesitant to push proprietary extensions than the Chrome team
521. # [11:06] * Parts: yatil (n=Adium@78.104.102.186)
522. # [11:06] <Philip`> That's not surprising given the different reactions those teams get when pushing proprietary extensions
523. # [11:06] * Joins: yatil (n=Adium@78.104.102.186)
524. # [11:07] <othermaciej> I think sending a portable low-level bytecode down the wire would be better than sending x86 code down the wire but apparently it's impossible for the world's brightest engineers to make that fast enough
525. # [11:07] * Joins: svtech (n=stanv@83.228.56.37)
526. # [11:08] <othermaciej> I did see some minor blowback about Native Client on the programming reddit, but some cheering too
527. # [11:08] <hsivonen> couldn't they at least spec a register-oriente abstract byte code, target LLVM to the byte code and ship JITs in the client?
528. # [11:08] <hsivonen> x86 seems like an awful choice for the universal bytecode
529. # [11:08] <Philip`> Or use the JVM, which is a pretty popular bytecode format
530. # [11:08] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
531. # [11:09] <Philip`> hsivonen: About X3D plugins vs native implementations: what about script implementations, which are neither? (Would it be worth changing the language to support those better?)
532. # [11:09] <jgraham> Everything old is new again?
533. # [11:10] <othermaciej> Native Client was interesting as a proof of concept but it won't be all that funny if Google starts posting x86 binaries as part of their Web apps
534. # [11:10] * Quits: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net)
535. # [11:11] <hsivonen> Philip`: for script implementations, I'd rather see script implementations of the feature set using WebGL and XHR before taking any steps to put it in the HTML parser in anticipation
536. # [11:11] <othermaciej> Philip`: seems to me like <object> and XMLHttpRequest respectively give all you need for plugin and script implementations
537. # [11:11] <othermaciej> apparently the X3D guys have a demo of it running on top of WebGL
538. # [11:12] * Joins: mat_t (n=mattomas@91.189.88.12)
539. # [11:12] <hsivonen> Philip`: I imagine Oracle would line up the lawyers if Google wanted to use the JVM byte code in workers without the standard library
540. # [11:13] <hsivonen> Philip`: there has to be a reason to do Dalvik
541. # [11:13] <hsivonen> Philip`: and if you invent a new byte code, you might as well make it register-based to avoid having to undo the stackness in the JIT
542. # [11:14] * Quits: gsnedders (n=gsnedder@c83-252-234-3.bredband.comhem.se)
543. # [11:15] <Philip`> I assume the X3D guys' demo is basically my demo from years ago, updated a bit
544. # [11:16] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
545. # [11:17] <Philip`> (which used inline X3D in XHTML)
546. # [11:17] <othermaciej> rendering to WebGL?
547. # [11:19] <annevk> might as well try to standardize JS bytecode then
548. # [11:19] * Quits: mat_t (n=mattomas@91.189.88.12) ("Leaving")
549. # [11:21] <Philip`> othermaciej: Rendering to Mozilla's GL API from years ago, which is basically the same as WebGL
550. # [11:22] * Quits: smaug (n=chatzill@cs181150024.pp.htv.fi) (Remote closed the connection)
551. # [11:22] * Philip` goes away
552. # [11:23] <Philip`> Oh, no I don't
553. # [11:24] <jgraham> Philip`: You're a bit early for pantomime season
554. # [11:30] * Joins: mat_t (n=mattomas@91.189.88.12)
555. # [11:34] <zcorpan> Philip`: any progress on end tag data?
556. # [11:34] * Joins: mitnavn (n=mitnavn@unaffiliated/mitnavn)
557. # [11:39] * Joins: smaug_ (n=chatzill@82.181.150.24)
558. # [11:41] <Philip`> zcorpan: No, I keep forgetting about it
559. # [11:41] <zcorpan> does it help that i keep reminding you about it?
560. # [11:42] <Philip`> Yes, because eventually you'll remind me at a time when I can't think of anything better to do :-)
561. # [11:42] <zcorpan> like now?
562. # [11:43] <Philip`> No
563. # [11:43] <zcorpan> bummer
564. # [11:45] <Hixie> man, the number of times i mistype "typo" isn't even funny
565. # [11:46] <zcorpan> you should have a macro key that types "typo"
566. # [11:49] <Hixie> hm, not a bad idea
567. # [11:50] <Hixie> unfortunately i need PS/2 to USB adapter to use my macro keyboard
568. # [11:50] <Hixie> and i'm out of keys to use for macros on my main keyboard
569. # [11:50] <Philip`> Use mouse gestures
570. # [11:51] <Philip`> Or you could use longer combinations of keys to activate the macro, for example "t"+"y"+"p"+"o"
571. # [11:51] <Hixie> mmmhm
572. # [11:55] * Joins: webben (n=benh@nat/yahoo/x-ttftclmbgjwbxbxp)
573. # [12:00] <Hixie> 19 e-mails remaining; 1 issues remaining; 24 bugs remaining!
574. # [12:00] <Hixie> totally doable by the end of the month
575. # [12:01] <zcorpan> yay
576. # [12:01] <jgraham> Can we have a WHATWG LC sweepstakes now? And a seperate HTMLWG one (with higher stakes)
577. # [12:02] * Joins: smaug (n=chatzill@82.181.150.24)
578. # [12:02] <jgraham> (since the probability distribution is rather broader and has a really long tail)
579. # [12:03] <Dashiva> Possibly infinite
580. # [12:03] <Philip`> Hixie: Does that mean you'll have time left over to rewrite the spec into rhyming couplets?
581. # [12:03] <Hixie> nooo
582. # [12:03] <Dashiva> What's wrong with pentameter?
583. # [12:06] <Philip`> Whoever decided that a pentameter contains five feet clearly wasn't an expert on measurement units
584. # [12:15] * Joins: workmad3 (n=davidwor@ashleys2.mimas.ac.uk)
585. # [12:15] * Joins: annevk42 (n=annevk@c-c604e353.13-500-64736c15.cust.bredbandsbolaget.se)
586. # [12:20] <AryehGregor> This spec aims to evolve HTML / and all of its related APIs, / to help the authoring of Web-based apps.
587. # [12:21] <AryehGregor> Hmm, now can I make it rhyme?
588. # [12:23] <Philip`> AryehGregor: Those aren't iambs, the stresses are all wrong :-(
589. # [12:23] <Philip`> Actually the second and third lines seem alright, but the first doesn't, unless I'm just reading it wrong
590. # [12:24] <AryehGregor> So sue me. I only even know what an iamb is because of some undergrad world humanities course three years ago that I didn't even mean to take.
591. # [12:25] <AryehGregor> You have to stress "to" in the first line, maybe that's wrong?
592. # [12:25] <AryehGregor> I dunno.
593. # [12:26] <Philip`> The pronunciation of "HTML" as four letters seems incompatible with the requirements
594. # [12:26] <Philip`> since I'd stress the "H" and "L"
595. # [12:26] <zcorpan> so pronounce it as "hutmel"
596. # [12:27] <Philip`> zcorpan: Too few syllables in that case
597. # [12:27] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 60 (Operation timed out))
598. # [12:27] <AryehGregor> Yeah, you have to stress the T and L instead of the H and L.
599. # [12:28] <AryehGregor> "Hypertext" is also a problem, so you can't just expand the acronym.
600. # [12:28] <Philip`> "Hypertext" seems okay to me
601. # [12:28] <mikekelly> =/
602. # [12:28] <Philip`> (as long as you follow it with something unstressed, i.e. not "Markup")
603. # [12:29] <AryehGregor> You'd have to stress it "HYperTEXT", I guess? I suppose that works.
604. # [12:29] <Philip`> though I'm certainly not an expert on any of these things and I barely know what a syllable is
605. # [12:30] <AryehGregor> You can read what I wrote as iambic pentameter if you want, anyway.
606. # [12:30] <AryehGregor> It's just not the most natural way to read it.
607. # [12:30] <AryehGregor> It's not like I'm putting stresses like "auTHORing" that are completely crazy.
608. # [12:30] <Philip`> It seems wholly unnatural to me :-)
609. # [12:30] <AryehGregor> Oh well.
610. # [12:30] <Philip`> (The first sentence anyway)
611. # [12:30] <Philip`> But don't ask me to produce anything better :-p
612. # [12:31] * Philip` wonders how Shakespeare would have written a play about HTML
613. # [12:31] <AryehGregor> Most of Shakespeare isn't in verse.
614. # [12:31] <AryehGregor> So he's safe.
615. # [12:31] * AryehGregor doesn't dare trying to rewrite even a single sentence of the spec in Elizabethan English
616. # [12:32] <AryehGregor> Archaic Hebrew I can do, English not so much.
617. # [12:32] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
618. # [12:40] * Quits: svtech (n=stanv@83.228.56.37) (No route to host)
619. # [12:42] * Joins: svtech (i=stanv@83.228.56.37)
620. # [12:45] * Quits: zcorpan (n=zcorpan@83.252.193.59)
621. # [12:50] * Quits: cedricv (n=cedric@112.199.133.135) (Connection reset by peer)
622. # [12:52] * Quits: wakaba_ (n=wakaba_@122.221.184.68) ("Leaving...")
623. # [12:53] * Joins: cedricv (n=cedric@124.197.105.239)
624. # [13:00] <mikekelly> Philip`: was it you was saying the other day a discussion came up about providing access to request object for a page?
625. # [13:01] <mikekelly> trying to find it but got no idea what I should be looking for :(
626. # [13:02] <hsivonen> Does this make sense: http://groups.google.com/group/mozilla.dev.tech.dom/msg/6dfd6196523b02e9 ?
627. # [13:02] <hsivonen> also, has the issue already moved to the WebApps WG?
628. # [13:06] <othermaciej> I don't recall addChild() being proposed
629. # [13:07] <othermaciej> the proposal strikes me as a little odd
630. # [13:08] <hsivonen> othermaciej: it's basically DWIM that hides the need to pass NS URIs to the APIs
631. # [13:08] <hsivonen> in Minefield, http://www.apple.com/imac/the-new-imac/#large plays the sound but no video
632. # [13:09] <othermaciej> why is append the only case of DOM insertion that needs a convenient built-in way to create the element?
633. # [13:09] <hsivonen> that's supposed to be HTML5 <video>, right?
634. # [13:10] <othermaciej> that page does use a <video> element (at least what it serves to Safari includes a <video> element)
635. # [13:10] <hsivonen> othermaciej: append is a natural excuse for taking an existing element as context
636. # [13:10] <annevk42> hsivonen, innerHTML strikes me as a much more convenient API
637. # [13:10] <hsivonen> annevk42: we don't have an efficient appendInnerHTML API
638. # [13:10] <othermaciej> hsivonen: to the point that you should fall completely off the API cliff if you want to prepend, insert, replace or make a detached subtree?
639. # [13:11] <hsivonen> annevk42: Firebug rolls its own using createContextualFragment
640. # [13:11] <othermaciej> actually, there's insertAdjacentHTML()
641. # [13:11] <othermaciej> (which I guess Mozilla doesn't have yet?)
642. # [13:11] <hsivonen> hmm. that could be useful
643. # [13:11] <hsivonen> assuming of course, that it's added to SVG elements, too
644. # [13:11] <hsivonen> no idea if Mozilla has it yet
645. # [13:11] <annevk42> I'm not too sure we should be inventing new DOM APIs before we have some more experience with what libraries are doing and what authors want
646. # [13:12] <othermaciej> insertAdjacentHTML is probably easier to use than what is proposed, though arguably more sloppy since it does runtime parsing of markup
647. # [13:12] <annevk42> especially since everything is already possible so it seems like too much premature optimization to me
648. # [13:12] <hsivonen> annevk42: libraries can deal with the horror of NS URIs anyway
649. # [13:12] <othermaciej> but it does solve the problems with using innerHTML to append though
650. # [13:12] <othermaciej> I too am hesitant to add DOM APIs
651. # [13:12] <annevk42> hsivonen, right, so why have new APIs?
652. # [13:12] <hsivonen> othermaciej: insertAdjacentHTML may be a nicer API if you don't need to vary the attribute values depending on program state
653. # [13:13] <othermaciej> I'd like to see us have a sound DOM4 Core draft that strips out the useless/unimplemented DOM APIs first, then consider additions very carefully
654. # [13:13] <othermaciej> hsivonen: depends on whether string-pasting is acceptable as a way to vary the attributes
655. # [13:13] <hsivonen> othermaciej: escaping them to be parser-safe seems awfully inefficient
656. # [13:13] <othermaciej> having to allocate a JS object to hold the attributes solely to pass them is an efficiency hit, though one that is common in JS libraries
657. # [13:13] <annevk42> I'm with othermaciej
658. # [13:13] <annevk42> that's pretty much what I'm doing for CSSOM
659. # [13:13] <Hixie> me too
660. # [13:14] <Hixie> what zcorpan was doing with Web DOM Core seemed like the right thing to do
661. # [13:15] <othermaciej> hsivonen: anyway I'm not totally convinced that the separateness of create and append is a major pain point
662. # [13:16] <othermaciej> hsivonen: I do think that dealing with the few well-known namespaces, and defining attributes after creating are real pain points
663. # [13:16] <othermaciej> hsivonen: on the other hand, why built-in handling for setting attributes but not text content?
664. # [13:17] <annevk42> is setAttribute() really that bad?
665. # [13:17] <jgraham> FWIW I find create+setAttribute being seperate to be a bigger pain point
666. # [13:17] <othermaciej> having to create and insert a Text node separately is kind of a pain
667. # [13:17] <hsivonen> when coding without libs on the raw DOM, creating and appending as separate ops sucks pretty badly, IMO
668. # [13:17] <jgraham> Oh yeah and the text node thing for sure
669. # [13:17] <annevk42> true, we should prolly overload a few methods at some point to also accept strings
670. # [13:17] <hsivonen> looks like the iMac ad uses <embed> in Minefield
671. # [13:17] <othermaciej> given that there are multiple useful ways to insert, there should be an uncombined version of the most convenient form of create
672. # [13:17] <hsivonen> no idea why the video doesn't render
673. # [13:18] * Joins: BlurstOfTimes (n=blurstof@168.203.117.66)
674. # [13:18] <othermaciej> in my raw DOM programming (mostly for WebKit test cases), the most annoying part of dynamically creating elements is usually making a text node to add text content
675. # [13:18] <jgraham> I sometimes create a wrapper funciton like Element(name, attributes, children)
676. # [13:18] <jgraham> where children can be a list of elements or text
677. # [13:18] <jgraham> But it's not a great design
678. # [13:19] <hsivonen> looks like Apple doesn't want to provide Theora video :-(
679. # [13:19] <othermaciej> is that in any way surprising?
680. # [13:19] <hsivonen> othermaciej: not really. just makes the hype about the ad using HTML5 fall a bit flat
681. # [13:20] <othermaciej> I guess assigning foo.textContent would be easier than creating a Text node, though less cross-browser portable
682. # [13:21] <annevk42> I usually set textContent
683. # [13:21] <annevk42> or innerHTML
684. # [13:21] <annevk42> depending on the string
685. # [13:21] <annevk42> and what browsers it needs to work in
686. # [13:21] <othermaciej> I use innerHTML or document.write() when I am lazy
687. # [13:21] <gsnedders|work> document.write() is just evil though
688. # [13:21] <hsivonen> I guess one might argue that all DOM sugaring that isn't perf-oriented like the Selectors API should just go in JS libs
689. # [13:21] <othermaciej> I guess that no longer stops my tests from being standards-compliant
690. # [13:22] <othermaciej> document.write() is only a little bit more evil than innerHTML
691. # [13:22] <hsivonen> othermaciej: document.write() is way, way more evil
692. # [13:22] <annevk42> ah yeah, I use document.write a lot too
693. # [13:22] <annevk42> very convenient for tests
694. # [13:22] <gsnedders|work> document.write() affects the parser as it is parsing. innerHTML doesn't do anything like that.
695. # [13:22] * hsivonen has spent insanely more time on implementing document.write than innerHTML
696. # [13:22] <gsnedders|work> Hence, document.write is more evil
697. # [13:23] <othermaciej> mere implementation concerns!
698. # [13:23] <annevk42> my test case writing trumps your implementing :p
699. # [13:23] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
700. # [13:23] <othermaciej> hsivonen: I think it's plausible that some sugar in the core would be useful, but if so it should be based on carefully studying what popular JS libraries do (perhaps after SVG-in-HTML and such is available)
701. # [13:24] <othermaciej> hsivonen: I think with Selectors API we made a mistake by not studying JS libs close enough, and ended up implementing something that didn't really work for them or their clients
702. # [13:24] <othermaciej> s/implementing/specifying and implementing/
703. # [13:25] * Joins: mat_t (n=mattomas@91.189.88.12)
704. # [13:26] * Parts: annevk42 (n=annevk@c-c604e353.13-500-64736c15.cust.bredbandsbolaget.se)
705. # [13:26] <jgraham> FWIW I don't think you should hace to pull in thousands of lines of jQuery to do simple things in a clean way
706. # [13:26] <othermaciej> agreed
707. # [13:26] <jgraham> But I agree that we shouldn't specify something that doesn't work for jQuery too
708. # [13:27] <othermaciej> in the case of DOM Core sugar, it would be more a question of whether it could serve the needs of jQuery (or Dojo or YUI) clients directly
709. # [13:27] <othermaciej> cause it doesn't matter that much what you use to implement the libraries
710. # [13:28] <othermaciej> it's actually kind of hard to make a sugary API that works better for implementing library-based convenience APIs, unless it exactly matches the API
711. # [13:28] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 113 (No route to host))
712. # [13:29] <jgraham> Arguably that means it doesn't matter too much if it meets the exact needs of the library since the use case would be people doing something too simple to want to pull in a whole complex library
713. # [13:29] <othermaciej> the question to ask would be how often does it save you from having to pull in the whole library
714. # [13:30] <jgraham> Indeed. For me it would be a big win but I'm quite atypical
715. # [13:30] <othermaciej> this is why I prefer such an API not to have a steep "cliff" - so if it doesn't do exactly what you want, you can just add a couple of other raw DOM calls, rather than having to find a completely separate way to do it
716. # [13:32] <mikekelly> which one is better to use - document.location.href or just document.location? or does it not make a diff?
717. # [13:32] <othermaciej> it doesn't really matter
718. # [13:32] <mikekelly> ok cool thanks
719. # [13:32] <mikekelly> do browsers store the location as an <a> tag then?
720. # [13:33] <mikekelly> also - are browsers coming up with a 'microformat' type giblet for storing bookmarks
721. # [13:33] <mikekelly> that would be snazzy
722. # [13:34] * Joins: dbaron (n=dbaron@c-69-140-1-234.hsd1.va.comcast.net)
723. # [13:41] <Philip`> mikekelly: It wasn't me
724. # [13:42] <gsnedders|work> mikekelly: No, they store the location as a URL (or as an entire DOMLocation object)
725. # [13:43] <gsnedders|work> mikekelly: It would make no sense to store it as an a element
726. # [13:44] <Philip`> othermaciej: Reported telecon date is wrong again :-p
727. # [13:44] <Philip`> Subject says 22, body says 15, link says 8
728. # [13:44] <othermaciej> dammit!
729. # [13:45] <Philip`> (of October)
730. # [13:45] <othermaciej> at least I got it right in the subject
731. # [13:45] <othermaciej> clearly too much copy-pastery involved
732. # [13:47] * Quits: annevk (n=annevk@pat.se.opera.com)
733. # [13:48] * Quits: webben (n=benh@nat/yahoo/x-ttftclmbgjwbxbxp) (Remote closed the connection)
734. # [13:53] * Quits: svtech (i=stanv@83.228.56.37)
735. # [14:00] <smaug_> Hixie: ping
736. # [14:00] <smaug_> Hixie: dnd doesn't seem to handle drop on form controls properly
737. # [14:01] <Hixie> how so?
738. # [14:01] <smaug_> basically, should drop fire?
739. # [14:02] <Hixie> generally speaking, yes
740. # [14:02] <smaug_> "If the dragover event is not canceled, the current drag operation must be reset to "none"."
741. # [14:03] <smaug_> "If the current drag operation is none (no drag operation), or, if the user ended the drag-and-drop operation by canceling it (e.g. by hitting the Escape key), or if the current target element is null, then the drag operation failed"
742. # [14:03] <smaug_> so what does cancel dragover when dropping to form controls?
743. # [14:04] <mikekelly> hmm seems the only way I can get headers for current page's response is to make a new HEAD request with XHR to document.location
744. # [14:04] <Hixie> smaug_: oh, i see. dragover should have some default behaviour that sets the current drag operation for form controls, or something
745. # [14:04] <Hixie> smaug_: send a mail or file a bug?
746. # [14:04] <smaug_> ok, will send a amil
747. # [14:04] <smaug_> mail
748. # [14:04] <mikekelly> is there any other way to approach this or is that the solution?
749. # [14:05] <Philip`> mikekelly: I think that's the only client-side solution
750. # [14:05] <Hixie> smaug_: thanks
751. # [14:05] <mikekelly> Philip`: so browser deliberately drop the response data once the page is loaded?
752. # [14:05] <Philip`> mikekelly: (You could instead approach it by passing everything through a proxy server that captures headers and returns them on demand, or something, but that wouldn't be great)
753. # [14:06] <Philip`> mikekelly: I believe so
754. # [14:06] <mikekelly> is there a specific reason for that or is it just how its ended up?
755. # [14:06] <Philip`> mikekelly: (or at least they don't expose it to scripts)
756. # [14:06] <Philip`> mikekelly: Features don't exist by default
757. # [14:07] <mikekelly> hmm I guess not
758. # [14:07] <Hixie> wow, did i really just address all those bugs?
759. # [14:07] <Hixie> it seems like the pile suddenly got smaller.
760. # [14:07] <mikekelly> most dev platforms make sure their APIs present all the relevant information :P
761. # [14:07] <mikekelly> fair enough though
762. # [14:08] <mikekelly> I doubt anyone will be convinced that is a good idea so looks like have to stick to making HEAD requests back
763. # [14:08] <mikekelly> all this inefficiency probably costs like.. a million trees a year or something like that
764. # [14:09] <Philip`> mikekelly: Seems unlikely, since it's a feature that approximately zero people want and emulate with HEAD requests
765. # [14:09] <Philip`> Also, trees are big and HTTP requests are tiny
766. # [14:09] <mikekelly> scale
767. # [14:09] <mikekelly> plus - people are moving away from message oriented approaches
768. # [14:10] <Philip`> Trees are really really big and HTTP requests are really really tiny
769. # [14:10] <mikekelly> and towards using HTTP headers for metadata
770. # [14:11] * Joins: svtech (i=stanv@83.228.56.37)
771. # [14:11] <mikekelly> so I don't think it's as crazy an idea as you think it is :P
772. # [14:12] * Joins: ciaran_lee (n=ciaran_l@ip-78-137-148-117.dub-tlght.metro.digiweb.ie)
773. # [14:13] <mikekelly> just a bit frustrating have to go back to fetch data that could've been made available already
774. # [14:14] <mikekelly> but hey - I'm sure it's within everyone's best interests to have it that way
775. # [14:14] <Philip`> It wouldn't be a problem if the server put all the needed data in the response body
776. # [14:14] <mikekelly> ;D
777. # [14:14] <mikekelly> that is not the same thing.
778. # [14:14] * Philip` doesn't think it's a crazy idea, he just doesn't care about it
779. # [14:15] * Quits: paul_irish (n=paul_iri@12.182.97.2) ("Leaving...")
780. # [14:15] <mikekelly> if you standardise your application's metadata in the headers you get metadata across all content-types
781. # [14:15] <mikekelly> jpg/png/html/doc/pdf/xml/json
782. # [14:16] <mikekelly> OCCI looks like it is going this way
783. # [14:16] <Hixie> ok bed time
784. # [14:16] <Hixie> nn
785. # [14:16] * Quits: yael (i=d0309a43@gateway/web/freenode/x-kginxvphzprqbxnb) ("Page closed")
786. # [14:17] * Joins: yael (i=d0309a43@gateway/web/freenode/x-eybxrvgkiaarbmzo)
787. # [14:18] <mikekelly> Philip`: you still disagree it is not equivalent to put metadata in the entity body?
788. # [14:18] * hsivonen wonders if Opera and WebKit have a pseudoclass for matchin on the HTMLness bit of the owner document
789. # [14:18] <hsivonen> Gecko has :-moz-is-html
790. # [14:21] <Philip`> mikekelly: I agree they're different, but that doesn't mean you can't put the data in the HTML entity body to avoid the problem of scripts wanting headers from the current response
791. # [14:21] <Philip`> (You might introduce other problems by doing that, of course)
792. # [14:24] * Quits: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net) ("Leaving...")
793. # [14:30] <mikekelly> Philip`: exactly :)
794. # [14:32] <Philip`> Would anyone shoot me for reporting WHATWG-copy-of-spec-specific issues in the W3C bug tracker?
795. # [14:33] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
796. # [14:33] <hsivonen> Philip`: people who disapprove of the existence of the WHATWG might
797. # [14:34] * Quits: svtech (i=stanv@83.228.56.37)
798. # [14:34] <hsivonen> Am I imagining things or does GCC run faster on Snow Leopard than on Leopard?
799. # [14:34] <hsivonen> x86_64 additional registers maybe?
800. # [14:35] <Philip`> Newer version of GCC?
801. # [14:37] <hsivonen> maybe
802. # [14:37] <hsivonen> no, actually, the big digits of the GCC version are supposed to be the same, I think
803. # [14:38] <hsivonen> hmm. did heycam ever file the bug about insertion modes when there are nested <td><svg>s?
804. # [14:39] <Philip`> Compiling for different targets (32-bit vs 64-bit)? or is it only the compiler itself that changed to 64-bit?
805. # [14:40] <hsivonen> Philip`: 32-bit target still
806. # [14:51] * Joins: webben (n=benh@nat/yahoo/x-yvdllixvxjckebzd)
807. # [14:53] * Quits: mitnavn (n=mitnavn@unaffiliated/mitnavn)
808. # [14:54] * Joins: mitnavn (n=mitnavn@unaffiliated/mitnavn)
809. # [15:01] * Joins: svtech (i=stanv@83.228.56.37)
810. # [15:03] * Joins: myakura (n=myakura@p2102-ipbf6805marunouchi.tokyo.ocn.ne.jp)
811. # [15:05] * Joins: zdobersek (n=zan@cpe-92-37-74-96.dynamic.amis.net)
812. # [15:07] * Quits: yatil (n=Adium@78.104.102.186) ("Leaving.")
813. # [15:10] * Joins: webben1 (n=benh@nat/yahoo/x-ynxjvwzbxjvasumb)
814. # [15:12] * Joins: miketaylr (n=miketayl@38.117.156.163)
815. # [15:17] <mikekelly> Philip`: meh - this works fine so can't really complain http://jsbin.com/eyobo
816. # [15:17] * Quits: webben (n=benh@nat/yahoo/x-yvdllixvxjckebzd) (Read error: 110 (Connection timed out))
817. # [15:17] <mikekelly> apart from the state of the resource being modified between requests..
818. # [15:18] <mikekelly> and the server providing inconsistent headers between GET/HEAD
819. # [15:18] <mikekelly> if you look at the content-length on that link it's actually wrong
820. # [15:18] <smaug_> Hixie: btw, could you remove initXXXEventNS methods from the draft? D3E draft doesn't have namespaced events anymore.
821. # [15:20] <Dashiva> He already did, I believe
822. # [15:20] <Dashiva> r4204
823. # [15:22] <smaug_> ah
824. # [15:22] <smaug_> hmm
825. # [15:22] <smaug_> did I load the draft from cache
826. # [15:23] <smaug_> I guess I did
827. # [15:31] * Quits: nessy (n=Adium@203-158-45-196.dyn.iinet.net.au) ("Leaving.")
828. # [15:41] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
829. # [15:49] * Joins: mpt (n=mpt@canonical/mpt)
830. # [15:54] * Joins: yutak_home (n=kee@61.117.6.79)
831. # [16:02] * Joins: mpilgrim (n=mark@adsl-162-132-170.rmo.bellsouth.net)
832. # [16:07] * Quits: svtech (i=stanv@83.228.56.37)
833. # [16:11] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
834. # [16:11] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 60 (Operation timed out))
835. # [16:16] * Quits: mpilgrim (n=mark@adsl-162-132-170.rmo.bellsouth.net) (Read error: 104 (Connection reset by peer))
836. # [16:17] * Joins: dglazkov (n=dglazkov@67.188.0.62)
837. # [16:17] * Joins: mpilgrim (n=mark@adsl-162-132-170.rmo.bellsouth.net)
838. # [16:20] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
839. # [16:23] <Philip`> mikekelly: Yeah, HEAD doesn't really work well enough to rely on if you don't control the server
840. # [16:23] <Philip`> If I remember correctly, I once found a server that returned four random bytes (like uninitialised memory or something) for Content-Type on HEAD requests
841. # [16:23] <mikekelly> which is why it would be nice to have access to the original request :P
842. # [16:24] <mikekelly> technically if a server isn't consistent across GET/HEAD then it''s breaking HTTP
843. # [16:25] <mikekelly> it's still annoyingly inefficient to have to make another request for information that's already been downloaded
844. # [16:28] <mikekelly> i'm not saying it should be - but how does stuff like that get standarised across browsers if it's decided it should be added?
845. # [16:29] * Joins: yatil (n=Adium@78.104.102.186)
846. # [16:30] * lmorchard|away is now known as lmorchard
847. # [16:33] <Philip`> mikekelly: Someone writes a specification for the stuff (often as part of an existing spec or working group), then someone convinces browser developers to implement it (by asking them, preferably showing usefulness and demand from users), then people write tests and documentation and stuff, and then everyone waits a few years until they can use it
848. # [16:33] <mikekelly> lol
849. # [16:33] <Philip`> (not necessarily in that order)
850. # [16:33] <mikekelly> I hope google chrome does well so we don't have to put up with nonsense much longer
851. # [16:34] <Philip`> Which nonsense?
852. # [16:34] <mikekelly> the nonsense you just described
853. # [16:34] <mikekelly> :P
854. # [16:35] <Philip`> The nonsense of developing clear specifications and getting browser developers to agree to implement it interoperably?
855. # [16:35] <mikekelly> yeah there's too many browsers that try to do too much
856. # [16:35] <TabAtkins> ...so you want a monoculture again?
857. # [16:35] <mikekelly> google chrome monoculture looks good to me
858. # [16:35] <TabAtkins> ::shudders::
859. # [16:36] <mikekelly> look at their extension system
860. # [16:36] <TabAtkins> There is no such thing as a good monoculture in tech.
861. # [16:36] <mikekelly> I'm sure Ian would have something to say about that
862. # [16:36] * Quits: dglazkov (n=dglazkov@67.188.0.62)
863. # [16:36] <TabAtkins> ?_?
864. # [16:37] <mikekelly> :D
865. # [16:37] <Philip`> I think I prefer standards rather than the alternative approach of Google adding hugely complex features willy-nilly and hoping they become de facto standards
866. # [16:37] <mikekelly> yeah I agree - personally I think browsers should do nothing other than render html/css and run javascript
867. # [16:37] <mikekelly> but that's just me
868. # [16:38] <mpilgrim> you're welcome to build one that does nothing but that
869. # [16:38] <mikekelly> I might well do that if I get time.
870. # [16:38] <mikekelly> or if that's what google chrom OS turns out to be I wont have to bother
871. # [16:39] <TabAtkins> Chrome OS is just going to be a light-weight Linux with a new windowing system that's designed to run webapps well, somehow.
872. # [16:39] * Joins: sylvaing (n=sylvaing@70-7-28-229.pools.spcsdns.net)
873. # [16:39] * Philip` was just at a talk about V8, and the person said Chrome OS wouldn't have device drivers written in JS :-(
874. # [16:39] <mikekelly> be cool to bootstrap my browser off my web server :)
875. # [16:39] <Philip`> mikekelly: By "cool" you mean "really slow"?
876. # [16:39] * mpilgrim still isn't sure what chrome os is
877. # [16:39] <mikekelly> Philip`: why would that be slow?
878. # [16:39] <TabAtkins> mpilgrim: It's what I just described.
879. # [16:40] <Philip`> It's an OS that's shiny
880. # [16:40] <Philip`> That's enough to get excited about
881. # [16:40] <mikekelly> if the core engine for rendering html/css and running javascript is on the client
882. # [16:40] <Philip`> No need to worry about technical details like what it is
883. # [16:40] <mikekelly> the rest is just UI components
884. # [16:40] * Joins: mpt (n=mpt@canonical/mpt)
885. # [16:41] <mikekelly> you recon it's not possible to design a browser UI with html5/css3/javascript?
886. # [16:41] <mikekelly> looks to me like it is/will be
887. # [16:41] <mpilgrim> i have that already
888. # [16:41] <mikekelly> well then.
889. # [16:41] <mpilgrim> it's called linux
890. # [16:42] <mpilgrim> (oops, that was responding to TabAtkins)
891. # [16:42] <mikekelly> yeah I know sorry =)
892. # [16:42] <TabAtkins> Yeah, just with a new windowing system, like I said.
893. # [16:42] * Joins: fishd (n=darin@67.180.164.209)
894. # [16:42] <mpilgrim> i like my windowing system
895. # [16:42] <TabAtkins> Then don't use Chrome OS. ^_^
896. # [16:43] <mpilgrim> but given the default windowing systems on various platforms, i can certainly see the market opportunity for one that doesn't suck
897. # [16:43] <mikekelly> I got one desktop on ubuntu full screen chrome
898. # [16:43] <mikekelly> does that count?
899. # [16:43] <Philip`> The V8 person suggested it was largely for people like his daughters, who use no applications other than the web browser
900. # [16:43] <TabAtkins> Yah, I think it's supposed to make the distinction between webapps/native apps mostly disappear too, like Chrome browser currently does with Application Shortcuts.
901. # [16:44] <TabAtkins> Only more so.
902. # [16:44] <Philip`> (which presumably doesn't apply to anybody who's in here)
903. # [16:44] <mikekelly> I don't think google will store any of this on the client
904. # [16:44] <mikekelly> well I wouldn't anyway
905. # [16:44] <Philip`> (Ah, the V8 person was Lars Bak)
906. # [16:45] <TabAtkins> Actually, I could get by pretty well with a browser-focused OS. My current spread of windows is pretty typical - 4 browser windows, IRC (in an FF plugin), and my music player.
907. # [16:45] * mpilgrim decides, apropos of nothing, that what "dive into html5" needs is a recurring "ask doctor markup" sidebar
908. # [16:46] <TabAtkins> mpilgrim: Ooh! Ooh! Make it be an <html> tag with glasses!
909. # [16:46] <TabAtkins> Like Dr. Swordopolis!
910. # [16:46] <mikekelly> I'd need a terminal client
911. # [16:46] <Philip`> Why only a doctor? Make him a professor, with crazy hair
912. # [16:46] <mpilgrim> ooh, i might even have clip art of a crazy-haired professor
913. # [16:46] <mikekelly> there's no way I'm going out to the fucking cloud just to get a terminal session going
914. # [16:46] <mpilgrim> now i'm going to lose the next two hours to looking at clip art
915. # [16:47] <TabAtkins> mikekelly: It's still going to be Linux.
916. # [16:47] <Philip`> mikekelly: What would you do with the terminal session, when all your data and applications are in the cloud?
917. # [16:47] <mikekelly> Philip`: connect to my shell
918. # [16:47] * Joins: taf2 (n=taf2@38.99.201.242)
919. # [16:47] <mikekelly> where irssi lives
920. # [16:48] <mikekelly> that is unless IRC moves onto HTTP
921. # [16:48] <mpilgrim> how about http://openclipart.org/people/johnny_automatic/johnny_automatic_little_professor.svg
922. # [16:49] <mikekelly> there's that mebbit thing I guess
923. # [16:49] * Joins: sgalineau (n=sylvaing@174-145-139-89.pools.spcsdns.net)
924. # [16:49] <TabAtkins> Dang that'd be good, mpilgrim.
925. # [16:50] <TabAtkins> sgalineau: http://www.engadget.com/2009/09/24/video-windows-7-launch-party-parody-is-bleeping-genius/
926. # [16:50] <Philip`> Trim out the background and have him point at the sidebar and I expect it'd be good
927. # [16:51] <mpilgrim> or http://commons.wikimedia.org/wiki/File:Stethoscope_(PSF).png
928. # [16:51] * mpilgrim hearts the Pearson Scott Foresman collection
929. # [16:52] <TabAtkins> I like the chubby professor.
930. # [16:52] <TabAtkins> He's adorable.
931. # [16:52] <Philip`> The person with the stethoscope scares me
932. # [16:53] <Philip`> I'm not even sure if it's male or female
933. # [16:53] <mpilgrim> chubby professor it is
934. # [16:54] <mpilgrim> and Professor Markup is born
935. # [16:54] <TabAtkins> Woo!
936. # [16:55] <mikekelly> lol.
937. # [16:57] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
938. # [17:00] * Joins: Midler (n=midler@94.191.165.92.bredband.tre.se)
939. # [17:00] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
940. # [17:02] * Joins: dglazkov (n=dglazkov@nat/google/x-uzgiuqanyiwyydzu)
941. # [17:02] * Quits: dglazkov (n=dglazkov@nat/google/x-uzgiuqanyiwyydzu) (Client Quit)
942. # [17:02] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
943. # [17:02] * Quits: sylvaing (n=sylvaing@70-7-28-229.pools.spcsdns.net) (Read error: 110 (Connection timed out))
944. # [17:03] * Joins: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
945. # [17:05] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) (Remote closed the connection)
946. # [17:05] * Quits: fishd (n=darin@67.180.164.209) (Read error: 145 (Connection timed out))
947. # [17:05] * Quits: lmorchard (n=lmorchar@66.103.254.157.static.a2webhosting.com) (Read error: 104 (Connection reset by peer))
948. # [17:07] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
949. # [17:10] * Joins: dglazkov (n=dglazkov@nat/google/x-sqmkolrsvoykpvxf)
950. # [17:13] * Joins: lmorchard (n=lmorchar@66.103.254.157.static.a2webhosting.com)
951. # [17:31] * Quits: sgalineau (n=sylvaing@174-145-139-89.pools.spcsdns.net) (Read error: 60 (Operation timed out))
952. # [17:35] * Joins: sylvaing (n=sylvaing@nat/microsoft/x-mrutoigfaxphbndk)
953. # [17:35] <ttepasse> Uh. <spacer> died.
954. # [17:37] * Joins: aroben (n=aroben@unaffiliated/aroben)
955. # [17:38] <Philip`> Nobody will mourn it
956. # [17:38] <mpilgrim> TabAtkins: http://diveintohtml5.org/canvas.html#reset
957. # [17:39] <TabAtkins> mpilgrim: I sort of think he needs a bit of a shadow to lift him off of the bottom border, but otherwise I love him to pieces.
958. # [17:39] * ttepasse has some nostalgia for these nn3 elements. Also: <multicol>.
959. # [17:40] <Philip`> How odd, that page is no longer unreadable in Opera
960. # [17:41] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
961. # [17:42] * Quits: yutak_home (n=kee@61.117.6.79) ("Ex-Chat")
962. # [17:42] <Philip`> http://diveintohtml5.org/canvas.html#pixel-madness - he's been scalped :-(
963. # [17:48] <mpilgrim> adding a min-height...
964. # [17:49] * Quits: zdobersek (n=zan@cpe-92-37-74-96.dynamic.amis.net) ("Leaving.")
965. # [17:49] <mpilgrim> CSS is awesome http://www.zazzle.com/css_is_awesome_mug-168716435071981928
966. # [18:09] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
967. # [18:09] * Quits: workmad3 (n=davidwor@ashleys2.mimas.ac.uk) (Read error: 110 (Connection timed out))
968. # [18:12] * Quits: mpilgrim (n=mark@adsl-162-132-170.rmo.bellsouth.net) (Read error: 110 (Connection timed out))
969. # [18:21] * Joins: maikmerten (n=maikmert@BAE2a5f.bae.pppool.de)
970. # [18:25] * Joins: weinig (n=weinig@17.203.15.239)
971. # [18:30] * Quits: mitnavn (n=mitnavn@unaffiliated/mitnavn)
972. # [18:35] * Joins: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi)
973. # [18:38] * Joins: ap (n=ap@17.246.19.174)
974. # [18:47] * Joins: jdouglas (n=jason@nat08.metaweb.com)
975. # [18:48] * Quits: ttepasse (n=ttepas--@p5B013979.dip.t-dialin.net) ("?Q")
976. # [18:48] * Joins: cying_ (n=cying@70.90.171.153)
977. # [18:48] * Quits: cying_ (n=cying@70.90.171.153) (Client Quit)
978. # [18:49] * Quits: cying (n=cying@adsl-75-18-219-50.dsl.pltn13.sbcglobal.net)
979. # [18:51] * Joins: erlehmann (n=erlehman@82.113.106.14)
980. # [19:06] * Quits: yael (i=d0309a43@gateway/web/freenode/x-eybxrvgkiaarbmzo) (clarke.freenode.net irc.freenode.net)
981. # [19:06] * Quits: daedb (n=daed@h11n1fls34o986.telia.com) (Remote closed the connection)
982. # [19:06] * Joins: yael (i=d0309a43@gateway/web/freenode/x-ximrlkbcuyksaanc)
983. # [19:09] * Joins: myakura_ (n=myakura@p2102-ipbf6805marunouchi.tokyo.ocn.ne.jp)
984. # [19:10] * Quits: myakura_ (n=myakura@p2102-ipbf6805marunouchi.tokyo.ocn.ne.jp) (Client Quit)
985. # [19:11] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
986. # [19:19] * Joins: ciaran_l1e (n=ciaran_l@ip-78-137-148-117.dub-tlght.metro.digiweb.ie)
987. # [19:22] * Quits: ciaran_lee (n=ciaran_l@ip-78-137-148-117.dub-tlght.metro.digiweb.ie) (Read error: 60 (Operation timed out))
988. # [19:25] * Quits: webben1 (n=benh@nat/yahoo/x-ynxjvwzbxjvasumb) ("Leaving.")
989. # [19:33] * Quits: michaelforrest (n=michaelf@91.189.88.12) (Read error: 104 (Connection reset by peer))
990. # [19:36] * Quits: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
991. # [19:39] * Quits: myakura (n=myakura@p2102-ipbf6805marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
992. # [19:45] * Joins: erlehmann_ (n=erlehman@82.113.121.7)
993. # [19:45] * Joins: cying (n=cying@70.90.171.153)
994. # [19:46] * Quits: sylvaing (n=sylvaing@nat/microsoft/x-mrutoigfaxphbndk) (Read error: 60 (Operation timed out))
995. # [19:50] * Joins: sebmarkbage (n=miranda@c29.a108.sto.bahnhof.net)
996. # [19:53] * Joins: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
997. # [19:56] * Quits: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) (Client Quit)
998. # [19:56] * Joins: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
999. # [19:59] * Joins: cying_ (n=cying@70.90.171.153)
1000. # [19:59] * Joins: zdobersek (n=zan@cpe-92-37-72-132.dynamic.amis.net)
1001. # [20:02] * Joins: weinig_ (n=weinig@17.246.17.253)
1002. # [20:04] * Joins: sbublava (n=stephan@77.117.11.62)
1003. # [20:04] * Quits: erlehmann (n=erlehman@82.113.106.14) (Read error: 110 (Connection timed out))
1004. # [20:04] * Joins: harth (n=heather@nat/mozilla/x-cdzskmxebxhczldq)
1005. # [20:05] * Quits: weinig (n=weinig@17.203.15.239) (Read error: 60 (Operation timed out))
1006. # [20:05] * weinig_ is now known as weinig
1007. # [20:05] * Joins: sylvaing (n=sylvaing@nat/microsoft/x-rnbrtjetreutmgmw)
1008. # [20:06] * aroben is now known as aroben|meeting
1009. # [20:07] * Quits: cying (n=cying@70.90.171.153) (Read error: 145 (Connection timed out))
1010. # [20:07] * cying_ is now known as cying
1011. # [20:11] * Joins: fishd (n=darin@nat/google/x-csrpewutnneowoaq)
1012. # [20:18] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
1013. # [20:18] * erlehmann_ is now known as erlehmann
1014. # [20:18] <yael> Hi, I am working on implementation of http://dev.w3.org/html5/spec/infrastructure.html#url-decomposition-idl-attributes, and I cannot find a clear explanation of what is a "Server-based naming authority". Can anyone here help me? thanks
1015. # [20:20] * Quits: sylvaing (n=sylvaing@nat/microsoft/x-rnbrtjetreutmgmw) (Read error: 60 (Operation timed out))
1016. # [20:20] * Joins: webben (n=benh@82.152.151.107)
1017. # [20:21] * Joins: franksalim (n=frank@76.221.202.115)
1018. # [20:23] * Joins: webben1 (n=benh@dip5-fw.corp.ukl.yahoo.com)
1019. # [20:29] * aroben|meeting is now known as aroben
1020. # [20:30] * Quits: gunderwonder (n=gunderwo@garage.upstruct.com)
1021. # [20:31] * Quits: weinig (n=weinig@17.246.17.253)
1022. # [20:31] * Joins: weinig (n=weinig@17.246.17.253)
1023. # [20:32] * Quits: cying (n=cying@70.90.171.153) (Remote closed the connection)
1024. # [20:32] * Joins: cying (n=cying@70.90.171.153)
1025. # [20:33] * Joins: dimich (n=dimich@nat/google/x-kwssrnisabzeqedg)
1026. # [20:38] * Quits: webben (n=benh@82.152.151.107) (Read error: 110 (Connection timed out))
1027. # [20:40] * Joins: mattl (n=mattl@fsf/staff/mattl)
1028. # [20:41] * Joins: jwalden (n=waldo@nat/mozilla/x-lrocotgpkoeuhfsa)
1029. # [20:41] * Quits: fishd (n=darin@nat/google/x-csrpewutnneowoaq) (Read error: 60 (Operation timed out))
1030. # [20:42] <mattl> i fear i'm going insane, but does a poster attr on a video tag really need to relative to the src URL?
1031. # [20:42] <anoopb> so twitpics api allows to upload/uploadandpost but not view pics?
1032. # [20:43] * Quits: webben1 (n=benh@dip5-fw.corp.ukl.yahoo.com) (Remote closed the connection)
1033. # [20:43] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
1034. # [20:51] * Joins: Super-Dot (n=Super-Do@66-240-27-50.isp.comcastbusiness.net)
1035. # [20:53] <Philip`> mattl: As far as I can tell, the spec says it's just relative to the normal document base URL
1036. # [20:54] <Philip`> (or technically the base URL of the <video> element)
1037. # [20:54] <Philip`> and src should be irrelevant
1038. # [20:56] * Joins: SuperDot_iPod (n=superdot@66-240-27-50.isp.comcastbusiness.net)
1039. # [20:58] * Quits: sbublava (n=stephan@77.117.11.62)
1040. # [20:58] * Quits: Super-Dot (n=Super-Do@66-240-27-50.isp.comcastbusiness.net) (Read error: 104 (Connection reset by peer))
1041. # [20:59] * Quits: weinig (n=weinig@17.246.17.253)
1042. # [21:00] * Quits: smaug (n=chatzill@82.181.150.24) (Remote closed the connection)
1043. # [21:01] * Joins: Super-Dot (n=Super-Do@66-240-27-50.isp.comcastbusiness.net)
1044. # [21:02] * Joins: daedb (n=daed@h11n1fls34o986.telia.com)
1045. # [21:02] * Quits: taf2 (n=taf2@38.99.201.242)
1046. # [21:03] * Joins: sicking (n=chatzill@c-69-181-197-163.hsd1.ca.comcast.net)
1047. # [21:03] * Parts: Super-Dot (n=Super-Do@66-240-27-50.isp.comcastbusiness.net)
1048. # [21:13] <TabAtkins> yael: I found this - http://www.cs.tut.fi/~jkorpela/rfc/2396/full.html - that looks somewhat useful.
1049. # [21:14] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) ("ChatZilla 0.9.85 [Firefox 3.7a1pre/20091020030931]")
1050. # [21:14] * Parts: SuperDot_iPod (n=superdot@66-240-27-50.isp.comcastbusiness.net)
1051. # [21:18] * Joins: smaug (n=chatzill@82.181.150.24)
1052. # [21:23] * Joins: ojan (n=ojan@72.14.229.81)
1053. # [21:35] <aroben> what's the recommended way to provide feedback on HTML5 these days? should I send an email to the list? should I use the comment form on the spec page?
1054. # [21:36] <TabAtkins> Use an email if you want to discuss the issue, or just file a bug in bugzilla.
1055. # [21:36] <TabAtkins> (The spec's comment form also works for this, though you won't automatically receive replies.)
1056. # [21:36] <aroben> TabAtkins: thanks
1057. # [21:37] * Quits: zdobersek (n=zan@cpe-92-37-72-132.dynamic.amis.net) ("Leaving.")
1058. # [21:41] * aroben is now known as aroben|lunch
1059. # [21:44] * Quits: maikmerten (n=maikmert@BAE2a5f.bae.pppool.de) (Remote closed the connection)
1060. # [21:46] * Joins: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
1061. # [21:52] <yael> TabAtkins: Thank you. The RFC 2396 says that "server-based naming authority" is tied to schemes that use IP based protocol. I have tested setting host and port on URLs with the sceme foo:. So I assume it should not work, but both IE8 and FF allowed that .
1062. # [21:52] * Joins: roc (n=roc@121.72.198.60)
1063. # [21:57] <TabAtkins> yael: I *really* don't have the experience necessary to answer that appropriately, but it does sound like unknown schemes probably shouldn't be assumed to use a server-based naming authority.
1064. # [21:58] <TabAtkins> Search the mailing list, though - I think I recall some discussion around that issue previously.
1065. # [21:58] * Joins: cying_ (n=cying@70.90.171.153)
1066. # [21:59] <yael> TabAtkins: thanks, appreciate your help.
1067. # [22:00] <TabAtkins> No problem.
1068. # [22:05] * aroben|lunch is now known as aroben
1069. # [22:06] * Quits: cying (n=cying@70.90.171.153) (Connection timed out)
1070. # [22:06] * cying_ is now known as cying
1071. # [22:10] * Joins: sylvaing (n=sylvaing@nat/microsoft/x-lmpuxjuonvqfmfnx)
1072. # [22:12] * Quits: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi) (Remote closed the connection)
1073. # [22:15] * Quits: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) ("Leaving")
1074. # [22:18] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com) (Remote closed the connection)
1075. # [22:27] * Quits: smaug_ (n=chatzill@82.181.150.24) ("ChatZilla 0.9.85 [Firefox 3.7a1pre/20091015073430]")
1076. # [22:35] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
1077. # [22:44] * Joins: taf2 (n=taf2@pool-98-117-216-229.bltmmd.fios.verizon.net)
1078. # [22:51] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 110 (Connection timed out))
1079. # [22:51] * Joins: weinig (n=weinig@17.246.17.253)
1080. # [22:52] * Joins: mpt (n=mpt@canonical/mpt)
1081. # [22:58] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
1082. # [22:59] * Quits: miketaylr (n=miketayl@38.117.156.163)
1083. # [22:59] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
1084. # [23:00] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu) (Client Quit)
1085. # [23:01] * Joins: jdouglas_ (n=jason@nat11.metaweb.com)
1086. # [23:02] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 60 (Operation timed out))
1087. # [23:02] * Quits: weinig (n=weinig@17.246.17.253)
1088. # [23:03] * Joins: weinig (n=weinig@17.246.17.253)
1089. # [23:03] * Joins: nessy (n=Adium@203-158-45-196.dyn.iinet.net.au)
1090. # [23:06] * Quits: cying (n=cying@70.90.171.153) (Remote closed the connection)
1091. # [23:06] * Joins: cying (n=cying@70.90.171.153)
1092. # [23:13] * Quits: cying (n=cying@70.90.171.153) (Read error: 131 (Connection reset by peer))
1093. # [23:13] * Joins: fishd (n=darin@nat/google/x-lsxrdwcjfovnbnrg)
1094. # [23:16] * Quits: jdouglas (n=jason@nat08.metaweb.com) (Read error: 110 (Connection timed out))
1095. # [23:16] * jdouglas_ is now known as jdouglas
1096. # [23:17] * Joins: mpt (n=mpt@canonical/mpt)
1097. # [23:17] * Joins: dave_levin (n=dave_lev@nat/google/x-nnaayhokfykjboio)
1098. # [23:19] * Joins: cying (n=cying@70.90.171.153)
1099. # [23:23] * Quits: weinig (n=weinig@17.246.17.253)
1100. # [23:24] * Joins: weinig (n=weinig@17.246.17.253)
1101. # [23:25] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
1102. # [23:28] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
1103. # [23:29] * Quits: weinig (n=weinig@17.246.17.253)
1104. # [23:30] * Quits: eml (i=eml@irk.bob.fi) (Read error: 104 (Connection reset by peer))
1105. # [23:30] * Quits: Midler (n=midler@94.191.165.92.bredband.tre.se) ("Leaving.")
1106. # [23:38] * Joins: and` (n=and@apo29.girton.cam.ac.uk)
1107. # [23:41] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
1108. # [23:42] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams) (Remote closed the connection)
1109. # [23:50] * Quits: fishd (n=darin@nat/google/x-lsxrdwcjfovnbnrg) (Read error: 110 (Connection timed out))
1110. # [23:50] * Joins: weinig (n=weinig@17.246.17.253)
1111. # [23:50] * Quits: BlurstOfTimes (n=blurstof@168.203.117.66) ("Leaving...")
1112. # [23:53] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
1113. # [23:57] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
1114. # [23:58] * Quits: zalan (n=zalan@catv-89-135-144-122.catv.broadband.hu) (Read error: 110 (Connection timed out))
1115. # Session Close: Thu Oct 22 00:00:00 2009

The end :)