/irc-logs / freenode / #whatwg / 2008-04-15 / end

Options:

1. # Session Start: Tue Apr 15 00:00:00 2008
2. # Session Ident: #whatwg
3. # [00:02] * Quits: tantek (n=tantek@99-200-252-246.area2.spcsdns.net)
4. # [00:03] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com) (Read error: 110 (Connection timed out))
5. # [00:05] <roc> that code doesn't seem to handle the SVG spread modes
6. # [00:06] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
7. # [00:06] * Joins: othermaciej_ (n=mjs@17.203.15.181)
8. # [00:07] * Quits: webben (n=benh@91.84.239.85) (Connection timed out)
9. # [00:07] <othermaciej> the intent is to use the same core code, if you want the details of how it is at the moment you'd have to ask hyatt
10. # [00:07] <alp> roc: might be an idea to propose sharing the SVG gradient implementation, or better, providing a patch
11. # [00:08] * Quits: aroben (n=adamrobe@unaffiliated/aroben)
12. # [00:08] * Joins: aroben (n=aroben@unaffiliated/aroben)
13. # [00:08] * Joins: hober (n=ted@unaffiliated/hober)
14. # [00:09] * Quits: othermaciej_ (n=mjs@17.203.15.181) (Client Quit)
15. # [00:10] * Quits: othermaciej (n=mjs@nat/apple/x-374d73756cd8d258)
16. # [00:10] * Joins: othermaciej (n=mjs@17.203.15.181)
17. # [00:10] <roc> yeah, that would be fun :-)
18. # [00:11] <roc> but seriously, platform/graphics/Gradient.cpp and svg/graphics/cairo/SVGPaintServerGradientCairo.cpp are clearly duplicating code, so I'm not sure what your comment "there's no reimplementation of anything" is supposed to mean
19. # [00:12] <othermaciej> roc: hyatt says css gradients share the back end with canvas but not with svg
20. # [00:13] * Joins: tor_ (n=tor@nat/ibm/x-2a6a870c98145fb1)
21. # [00:13] <alp> roc: Philip` was asking if webkit was re-implementing rasterisation code or using platform APIs. it is the latter
22. # [00:13] * Joins: dhyatt (n=hyatt@c-98-200-231-139.hsd1.tx.comcast.net)
23. # [00:15] <roc> ok
24. # [00:15] <dhyatt> roc: othermaciej said you had questions about the gradient stuff
25. # [00:15] <roc> hello!
26. # [00:16] <roc> I'm afraid of a gradual import of all of SVG paint servers into CSS and would rather see a general reuse of SVG paint servers
27. # [00:16] <roc> possibly with some CSS syntax
28. # [00:17] <dhyatt> how would you link to svg though
29. # [00:17] <roc> but since you're not reusing your SVG code that way, divergence seems inevitable, which worries me
30. # [00:17] <dhyatt> i plan to unify all of our gradient code
31. # [00:17] <dhyatt> canvas and the new css feature use the same back end gradient* object
32. # [00:17] * Quits: heycam (n=cam@210-84-23-247.dyn.iinet.net.au) ("bye")
33. # [00:17] <dhyatt> i'm going to try to unify svg with it
34. # [00:18] <roc> good
35. # [00:18] <andersca_> the grand unification theory
36. # [00:19] <dhyatt> canvas is sharing with this
37. # [00:20] <roc> I haven't got a concrete proposal, I'm afraid, but you could allow "fill: url(foo.svg#elem)" on arbitrary elements, perhaps
38. # [00:20] * Philip` guesses specs will need to be careful to give consistent definitions, if the implementations are going to be shared
39. # [00:20] <roc> that's the problem
40. # [00:20] <roc> the only safe thing to do is to incorporate by reference
41. # [00:20] <Philip`> (Opera complained about the canvas gradient spec being nasty, and it'd be better to follow SVG more closely)
42. # [00:21] * Quits: qwert666_ (n=qwert666@acav178.neoplus.adsl.tpnet.pl) ("Leaving")
43. # [00:22] <roc> or we could deal with CSS syntax for gradients, even, as long as the spec says "this is equivalent to the SVG: ..."
44. # [00:22] <dhyatt> i have no real opinion about which gradient definition to follow
45. # [00:22] <roc> apart from ensuring common behaviour, it's also important to get common evolution
46. # [00:22] <dhyatt> i think pointing to an svg gradient from css is ok but kind of defeats the point
47. # [00:23] <dhyatt> which is to not have to load another file to render a gradient :)
48. # [00:23] <roc> why?
49. # [00:23] <roc> data: !
50. # [00:23] <roc> or HTML5 <svg>
51. # [00:23] <dhyatt> that would be super clunky compared to just having a native gradient syntax in css though
52. # [00:24] <roc> or something new
53. # [00:24] <annevk> C4X
54. # [00:24] <roc> well like I said, native gradient syntax in CSS isn't so bad
55. # [00:25] <dhyatt> i think it's fine to be able to point to an svg gradient
56. # [00:25] <dhyatt> i just don't think anyone would use it if you could just use straight css :)
57. # [00:25] <dhyatt> unless it had functionality you couldn't get from the css version
58. # [00:26] <roc> external SVG references would let you do any paint server, including future SVG extensions
59. # [00:27] <roc> my main concern is that if the spec says more than "this CSS is equivalent to this SVG" then inevitably the specs will diverge
60. # [00:27] <roc> either by mistake, or via extensions in one spec or the other
61. # [00:28] <roc> same bad feeling as when SVG 1.2 started dragging in HTML+CSS text layout, one feature at a time
62. # [00:29] * Joins: othermaciej_ (n=mjs@nat/apple/x-fcb6a4ae6fcb69ce)
63. # [00:29] <dhyatt> i don't really view gradients as the sole province of svg though
64. # [00:30] <dhyatt> gradients were in use as background images on web sites before svg existed
65. # [00:30] <roc> it's not about a turf war or who was there first, it's about sharing code, specs and brainprint
66. # [00:30] <shepazu> I agree with dhyatt here
67. # [00:30] <shepazu> but I also agree with roc
68. # [00:30] <othermaciej> just because SVG includes gradients doesn't mean gradients are a "vector graphics" feature
69. # [00:30] <shepazu> :)
70. # [00:30] <dhyatt> yeah, i'm not disagreeing with the idea of saying the gradients behave the same as svg
71. # [00:31] <dhyatt> or that the code should be shared internally
72. # [00:31] <dhyatt> that all sounds good to me
73. # [00:31] <shepazu> making it a consistent model for developers is what I would aim for
74. # [00:31] <dhyatt> but for example, for os x, we might add custom extensions to make all the coreimage generators work
75. # [00:32] <shepazu> that is, page authors... but to a lesser extent, browser developers as well
76. # [00:32] <dhyatt> they don't necessarily have svg equivalents
77. # [00:32] <dhyatt> (nor would this be proposed as a spec or anything)
78. # [00:32] <roc> fine, but I'm sure you can figure that out
79. # [00:33] * Quits: othermaciej_ (n=mjs@nat/apple/x-fcb6a4ae6fcb69ce) (Client Quit)
80. # [00:33] <othermaciej> what other generators does CoreImage have?
81. # [00:35] <dhyatt> lenticular halos, starbursts, checkerboards, ummm
82. # [00:35] <Philip`> Ooh, can I cover my web page in lens flares?
83. # [00:35] <dhyatt> stripes, star shine
84. # [00:35] <dhyatt> i think that's all of them
85. # [00:35] <othermaciej> lens flares would be more of a filter effect than a generator
86. # [00:35] <dhyatt> can do gaussian gradients too
87. # [00:39] <dhyatt> i would need to do research to understand what is different about svg gradients vs. canvas gradients
88. # [00:39] <dhyatt> Philip said opera disliked something about canvas gradients
89. # [00:41] <Philip`> dhyatt: http://lists.w3.org/Archives/Public/public-html/2007Oct/0336.html
90. # [00:41] <dhyatt> anyway, not interested in starting some kind of svg turf war :)
91. # [00:42] <Philip`> http://lists.w3.org/Archives/Public/public-html/2007Oct/0350.html says some things about canvas vs SVG definitions
92. # [00:43] <Philip`> (Only WebKit almost implements canvas radial gradients according to the spec)
93. # [00:43] <Philip`> (and that's mostly because the spec was written to match WebKit, since the other implementations were too buggy)
94. # [00:44] <dhyatt> i see.
95. # [00:44] <dhyatt> so my radial gradient syntax is "canvas-biased"
96. # [00:44] <roc> "uh oh"
97. # [00:45] <dhyatt> or more accurately "cg-biased"
98. # [00:45] <dhyatt> since canvas itself is cg-biased
99. # [00:46] <Philip`> CG varies a bit at radial gradients between OS X 10.4 and 10.5, which makes it more fun
100. # [00:47] <dhyatt> i don't really understand the difference rendering-wise
101. # [00:47] <Philip`> (I suppose that's only in edge cases, but I'm pointlessly interested in edge cases)
102. # [00:48] <dhyatt> how would you translate the svg way into cg
103. # [00:48] <othermaciej> dhyatt: I really want gradients for text, but I guess the best way to do that is to allow some general sense of fill rules for text in CSS
104. # [00:48] <dhyatt> i guess i could just look at our code heh
105. # [00:48] <dhyatt> othermaciej: yeah, background-clip: text does it, but that's kind of a hack
106. # [00:48] <dhyatt> othermaciej: fantasai suggested possibly a text-fill
107. # [00:49] <dhyatt> we already have text-fill-color
108. # [00:49] <dhyatt> that could become part of a larger shorthand
109. # [00:49] <othermaciej> yeah, I mean, what if I want to do gradient text on a different gradient background?
110. # [00:49] <othermaciej> for my Super Swingin' '70s blog
111. # [00:49] <dhyatt> well because of multiple backgrounds you ca nactually do that
112. # [00:49] <dhyatt> evne using the background-clip: text hack
113. # [00:49] <othermaciej> background-clip: text only clips the frontmost background?
114. # [00:49] <dhyatt> but i don't like the hack since it puts the text rendering at the background level
115. # [00:49] <dhyatt> so selection looks funny
116. # [00:49] <dhyatt> and text dragging doesn't draw right
117. # [00:50] <dhyatt> othermaciej: no you can clip any background in the stack
118. # [00:50] <dhyatt> so you can create some intriguing effects :)
119. # [00:50] <othermaciej> oh, background-clip can apply to any background?
120. # [00:50] <othermaciej> I see
121. # [00:50] <dhyatt> since one in the middle can clip to text and then a higher background can even overlay it with transparency
122. # [00:52] * Quits: tndH (i=Rob@adsl-87-102-38-69.karoo.KCOM.COM) ("ChatZilla 0.9.81-rdmsoft [XULRunner 1.8.0.9/2006120508]")
123. # [00:53] <dhyatt> ok dinner
124. # [00:53] * Quits: dhyatt (n=hyatt@c-98-200-231-139.hsd1.tx.comcast.net)
125. # [00:54] * Joins: mcarter (n=mcarter@ip-12-22-56-126.hqglobal.net)
126. # [00:54] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
127. # [00:54] <mcarter> hello
128. # [00:55] <Philip`> mcarter: Hello
129. # [00:56] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
130. # [00:56] * Philip` sees http://benjamin.smedbergs.us/blog/2008-04-14/hgweb-viewer-canvas-version/ on SVG vs canvas
131. # [01:03] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
132. # [01:12] * Joins: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
133. # [01:13] <jacobolus> Hixie: so does webkit's continual adding of new stuff make you annoyed that you'll have to keep adding new specs, or glad that browsers are innovating again? :p
134. # [01:14] <roc> great, once again our bacon is saved by an undocumented WK* API.
135. # [01:14] <Hixie> so long as they keep adding css stuff, it becomes the problem of the css wg, not ours :-)
136. # [01:14] <jacobolus> Hixie: by the way, I very much like the changes to the Server-Sent Events spec. I'm not sure when that was changed (sometime in the last 2-3 months?) but the changes make it much cleaner and more useful.
137. # [01:15] <Hixie> yeah it wasn't too long ago
138. # [01:15] <Hixie> glad you like 'em
139. # [01:16] <jacobolus> Hixie: my friend (and maybe I'll help him out w/ this) plans to implement a javascript shim to handle SSE streams from Firefox/Safari/Opera using xhr
140. # [01:16] <Hixie> nice
141. # [01:16] <jacobolus> and from IE using iframes inside htmlfile activex objects
142. # [01:16] <jacobolus> but that won't be quite perfect
143. # [01:16] <jacobolus> because IE requires 256 bytes of padding before incremental rendering
144. # [01:17] <jacobolus> (as will safari under Tiger :/)
145. # [01:17] <Hixie> :-/
146. # [01:18] <jacobolus> but anyway, if/when that is done, it should be rather easier to handle the server end
147. # [01:19] <Philip`> Could you transparently add 256-byte comments into the output stream?
148. # [01:20] <jacobolus> Philip`: yes
149. # [01:20] <jacobolus> Philip`: but you have to do it from the server side
150. # [01:20] * Philip` is reminded of the X-Pad and X-Pad-For-Netscrape-Bug HTTP headers
151. # [01:20] <jacobolus> which means that the browser end won't be a perfect implementation of the spec
152. # [01:20] <Philip`> Ah
153. # [01:20] <jruderman> is that because of sniffing for feeds and other non-HTML content?
154. # [01:20] <jacobolus> so server makers would still have to implement spec+
155. # [01:21] <Hixie> growing pains
156. # [01:21] <Hixie> it happens
157. # [01:21] <Philip`> It doesn't necessarily happen - you just have to stop growing
158. # [01:21] <jacobolus> jruderman: in the Webkit/<10.4 case, it's because of the OS network I/O routines used
159. # [01:21] <jacobolus> which they fixed in 10.5
160. # [01:22] <jruderman> ok
161. # [01:22] <jacobolus> in the IE case, I'm not sure
162. # [01:22] <jacobolus> I think it's because using iframes for Comet is basically an unanticipated hack :p
163. # [01:22] * Quits: tor_ (n=tor@nat/ibm/x-2a6a870c98145fb1)
164. # [01:25] * Quits: billmason (n=billmaso@ip200.unival.com) (".")
165. # [01:25] <jacobolus> Hixie: is it true that the latest Opera went and implemented the complete few-months-ago version of SSE?
166. # [01:26] <KevinMarks> "will HTML5 help fix the back button problem?"
167. # [01:26] <Hixie> jacobolus: they implemented it long ago
168. # [01:26] <Hixie> jacobolus: before the spec changed
169. # [01:26] <jacobolus> Hixie: no, that was a very *incomplete* implementation
170. # [01:26] <Hixie> jacobolus: oh
171. # [01:26] <Hixie> jacobolus: i don't know of any other work
172. # [01:26] <Hixie> jacobolus: it's possible
173. # [01:26] <Hixie> jacobolus: in either case the two can live side-by-side, as they have different MIME types
174. # [01:26] <jacobolus> someone was telling me they had implemented much more of the spec (but still before it changed)
175. # [01:29] * Quits: KevinMarks (n=KevinMar@219.sub-70-198-113.myvzw.com) ("The computer fell asleep")
176. # [01:42] * Quits: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
177. # [01:53] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
178. # [01:58] * Joins: KevinMarks (n=KevinMar@5.sub-75-220-64.myvzw.com)
179. # [02:00] * Joins: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
180. # [02:00] * Quits: othermaciej (n=mjs@17.203.15.181)
181. # [02:00] * Joins: andersca (n=andersca@nat/apple/x-40ddb6e96f7f423c)
182. # [02:14] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
183. # [02:21] * Quits: andersca_ (n=andersca@17.255.106.236) (Read error: 110 (Connection timed out))
184. # [02:25] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
185. # [02:28] * Quits: KevinMarks (n=KevinMar@5.sub-75-220-64.myvzw.com) ("The computer fell asleep")
186. # [02:50] <mcarter> Hixie, out of curiosity, what was the driving force behind the SSE changes? Is there a mailing list thread about it?
187. # [02:51] <Philip`> mcarter: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-February/014027.html hopefully covers the relevant points
188. # [02:51] <Hixie> yeah that's the main summary
189. # [02:52] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
190. # [02:52] <mcarter> Philip`, thanks
191. # [02:52] <Hixie> http://www.google.com/search?q=%22received+was+when+it+reconnects,+so+as+to+allow+seamless+continuation%22&hl=en&client=firefox-a&rls=org.mozilla:en-US:official&hs=m4t&filter=0 has that message in other archives
192. # [02:53] <Hixie> in case you can find one that actually links to the e-mails listed in the "References" headers
193. # [02:53] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) (Read error: 110 (Connection timed out))
194. # [02:54] <Philip`> Hixie: The References header points at http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0137.html http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0138.html http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0165.html
195. # [02:54] <Philip`> which are about something totally different
196. # [02:55] <Hixie> exclusively, or amongst other things?
197. # [02:55] <Philip`> Exclusively
198. # [02:55] <Hixie> i believe those e-mails were part of those that i had looked at when creating that e-mail, but i don't know why it would only list those
199. # [02:55] <Hixie> you sure that the original e-mail didn't include anything else?
200. # [02:55] <Philip`> Message-ID: <Pine.LNX.4.62.0802212051290.6407@hixie.dreamhostps.com>
201. # [02:55] <Philip`> References: <0b2b01c8730f$d41b1ef0$4200a8c0@kris> <op.t6r4mdhm64w2qv@annevk-t60.oslo.opera.com> <E23F5599-9BDB-4723-A3AC-D9B80B1BBD45@dojotoolkit.org>
202. # [02:55] <Philip`> Content-Language: en-GB-hixie
203. # [02:55] <Hixie> huh
204. # [02:55] <Hixie> weird
205. # [02:56] <Hixie> how many references does my mathml/svg mail have?
206. # [02:56] <Hixie> that one should have 620
207. # [02:56] <Hixie> maybe pine is truncating the list
208. # [02:56] <Hixie> when it sends it out
209. # [02:56] <Hixie> that would suck
210. # [02:56] <Dashiva> 620... references...
211. # [02:56] <Philip`> 1
212. # [02:57] <Philip`> Message-ID: <Pine.LNX.4.62.0804060112390.18949@hixie.dreamhostps.com>
213. # [02:57] <Philip`> References: <op.t8402scsidj3kv@hp-a0a83fcd39d2.belkin>
214. # [02:57] <Philip`> Content-Language: en-GB-hixie
215. # [02:57] <Hixie> crap
216. # [02:57] <Hixie> silly mail client
217. # [02:57] <Philip`> (assuming Gmail doesn't do anything stupid on received mail)
218. # [02:57] <Hixie> oh gmail almost certainly does something stupid
219. # [02:57] <Hixie> in its display, at least
220. # [02:57] <Hixie> but pine might well also do something stupid
221. # [02:58] <Philip`> This is the raw "Show original" display
222. # [02:58] <Philip`> http://lists.w3.org/Archives/Public/public-html/2008Apr/0205.html only lists the one "In reply to" too
223. # [02:58] <jacobolus> that's unfortunate :/
224. # [02:58] <Hixie> well bummer
225. # [02:59] <Hixie> well, the w3c archives only list the In Reply To lines for things in the same month archive
226. # [02:59] <Hixie> so that might not mean much in general, though in this case it should be including far more
227. # [02:59] <Hixie> i guess pine is trimming my in-reply-to or references: headers
228. # [02:59] * Joins: othermaciej (n=mjs@17.203.15.181)
229. # [02:59] <Hixie> that sucks
230. # [02:59] <Dashiva> What mail was it you wanted to check?
231. # [03:00] <Dashiva> "Supporting MathML and SVG in text/html, and related topics" <-- that?
232. # [03:00] <Hixie> yeah
233. # [03:00] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Connection timed out)
234. # [03:01] <Dashiva> Only one references here too.
235. # [03:02] <Dashiva> How would you make it reference all those mails anyhow? Is there a "reply to many mails at once" thing?
236. # [03:02] <Hixie> yes
237. # [03:03] <Philip`> You should write all your SMTP messages by hand, to make sure it does what you expect
238. # [03:03] <Hixie> i don't care enough :-)
239. # [03:05] <Dashiva> Make the mail client represent your inbox as a graph, then draw lines from the mails you want to reference
240. # [03:05] <Hixie> the ui part is solved, in pine
241. # [03:05] <Hixie> i just wish it actually did the right thing
242. # [03:06] <Dashiva> So it lists all the references at the top of the screen, not just an invisible list based on your initial reply selection?
243. # [03:10] <Hixie> the ui should be non-existent for this
244. # [03:11] <Hixie> i can select messages to reply to
245. # [03:11] <Hixie> it should automatically refer to all of these elements
246. # [03:13] <Hixie> ok i dunno wtf just happened but the last few checkins are a mess
247. # [03:15] <Hixie> entities just updated too, btw
248. # [03:20] * Joins: MikeSmith (n=MikeSmit@EM60-254-241-0.pool.e-mobile.ne.jp)
249. # [03:21] * Joins: JohnResig_ (n=jresig@c-76-118-158-44.hsd1.ma.comcast.net)
250. # [03:22] * Quits: JohnResig (n=jresig@c-76-118-158-44.hsd1.ma.comcast.net) (Read error: 104 (Connection reset by peer))
251. # [03:22] * Joins: tor (n=tor@cpe-24-28-29-26.austin.res.rr.com)
252. # [03:25] * Quits: JohnResig_ (n=jresig@c-76-118-158-44.hsd1.ma.comcast.net) (Read error: 104 (Connection reset by peer))
253. # [03:35] * Joins: JohnResig (n=jresig@c-76-118-158-44.hsd1.ma.comcast.net)
254. # [03:39] * Quits: eseidel (n=eseidel@nat/google/x-b17c94220ccc4216)
255. # [03:48] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
256. # [03:53] * Quits: weinig (n=weinig@17.203.15.172)
257. # [03:58] <Hixie> i wonder what i should work on next
258. # [03:59] * Quits: MikeSmith (n=MikeSmit@EM60-254-241-0.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
259. # [04:00] <Philip`> Find a section of the spec that is being implemented, and then rewrite it to be totally different
260. # [04:01] <Hixie> sweet, we broke the 3000 e-mail point
261. # [04:02] <Hixie> only 2961 e-mails on the pile now
262. # [04:02] <Hixie> the number has gone down 900 e-mails since oct 3 last year
263. # [04:03] <Hixie> that's one e-mail every 5 or so hours
264. # [04:04] <Hixie> about 4.5 e-mails a day average over 6 months
265. # [04:05] <Hixie> 658 days to go if there are more months like january where i do no html5 work
266. # [04:05] <Philip`> "ack r12n for the last checkin" - s/r12n/r12a/ :-p
267. # [04:05] <Philip`> Oh
268. # [04:06] <Hixie> yeah i tried to correct it but half the checkin was already in
269. # [04:06] * Philip` reads the more recent commit message
270. # [04:06] <Philip`> I thought SVN did atomic transactions so it wouldn't do half a checkin
271. # [04:06] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
272. # [04:07] <Hixie> guess not
273. # [04:17] * Joins: Thezilch (n=fuz007@cpe-76-170-22-23.socal.res.rr.com)
274. # [04:19] * Joins: MikeSmith (n=MikeSmit@dhcp-247-165.mag.keio.ac.jp)
275. # [04:19] * Quits: andersca (n=andersca@nat/apple/x-40ddb6e96f7f423c) (Read error: 110 (Connection timed out))
276. # [04:21] * Joins: kfish (n=conrad@61.194.21.25)
277. # [04:30] * Joins: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
278. # [04:38] * Quits: sverrej (n=sverrej@89.10.27.179) (Read error: 110 (Connection timed out))
279. # [04:38] * Joins: sverrej (n=sverrej@169.80-203-30.nextgentel.com)
280. # [04:59] * Joins: sverrej_ (n=sverrej@89.10.27.86)
281. # [05:10] * Quits: sverrej (n=sverrej@169.80-203-30.nextgentel.com) (Read error: 110 (Connection timed out))
282. # [05:16] * Quits: othermaciej (n=mjs@17.203.15.181)
283. # [05:18] * Joins: othermaciej (n=mjs@nat/apple/x-cb7eaa67be542f3e)
284. # [05:19] * Joins: crschmidt (i=crschmid@bia.crschmidt.net)
285. # [05:20] <crschmidt> So, I'm using the client side storage stuff in Safari. and I'm wondering how to do 'give this insert the next available monotonically increasing ID'
286. # [05:20] <crschmidt> be it via sequences, auto_increment, or something else.
287. # [05:20] <crschmidt> I googled a bit and didn't find anything useful: Am I missing something obvious?
288. # [05:21] <crschmidt> (I realize this is probably implementation specific, but I don't even know where to start.)
289. # [05:29] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
290. # [05:31] <jwalden> it would be; <editorialize>it's unconscionable, but the SQL stuff in the HTML5 drafts doesn't specify a subset of SQL which must be supported, which is absolutely horrible given how much HTML5 has concerned itself with implementation compatibility elsewhere</editorialize>; people in #webkit would know, not sure whether they mind fielding such questions or not, tho
291. # [05:38] * Quits: MikeSmith (n=MikeSmit@dhcp-247-165.mag.keio.ac.jp) (Excess Flood)
292. # [05:38] * Joins: MikeSmith (n=MikeSmit@dhcp-247-165.mag.keio.ac.jp)
293. # [05:39] <othermaciej> read the MySQL docs
294. # [05:40] <crschmidt> jwalden: Sure it does! It says 'the subset of SQL which must be supported will be defined in the future'
295. # [05:40] <crschmidt> :)
296. # [05:40] <crschmidt> othermaciej: thanks
297. # [05:40] <jwalden> copout
298. # [05:40] <roc> MySQL? I would have though SQLite
299. # [05:40] <othermaciej> oh yeah
300. # [05:40] <othermaciej> SQLite
301. # [05:40] <jwalden> and not useful since it's already implemented and shipping in a browser (I think?)
302. # [05:41] <othermaciej> see, even I can't keep it straight
303. # [05:41] <jwalden> not sure whether 3.1 got it or not
304. # [05:41] <crschmidt> jwalden: it did
305. # [05:41] <crschmidt> that's what I'm testing with :)
306. # [05:41] <jwalden> that's what I /thought/ but I wasn't willing to say so without certainty
307. # [05:41] * crschmidt nods
308. # [05:41] <crschmidt> Oh, so it is sqlite: well, I was trying the write database syntax, but apparently something about it just doesn't like me
309. # [05:41] <crschmidt> oh well
310. # [06:07] * Quits: othermaciej (n=mjs@nat/apple/x-cb7eaa67be542f3e)
311. # [06:17] * Quits: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
312. # [06:34] * Joins: MacDome (n=eric@adsl-76-203-74-203.dsl.pltn13.sbcglobal.net)
313. # [06:35] * Quits: tor (n=tor@cpe-24-28-29-26.austin.res.rr.com)
314. # [06:53] * Quits: MacDome (n=eric@adsl-76-203-74-203.dsl.pltn13.sbcglobal.net)
315. # [07:00] * crschmidt wonders if he would be better advised to implement Gears support explicitly in his code or beg someone to make gears match up slightly more closely with the whatwg spec
316. # [07:18] <crschmidt> Oh well, Google Gears support added now
317. # [07:22] <bradee-oh> crschmidt: while you're doing the GG support for now... *also* beg someone to make gears better match up with the spec ;)
318. # [07:23] * crschmidt doesn't even have anyone to beg
319. # [07:31] * Quits: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
320. # [07:39] <Hixie> jwalden: i really do want to specify the sql language to be supported, but we need implementation experience before we can do that
321. # [07:40] <Hixie> jwalden: speccing in a vacuum results in crappy specs :-)
322. # [07:40] <jwalden> do you really want to know how far down the SQL syntax rabbit hole goes?
323. # [07:41] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
324. # [07:42] <jwalden> because, given the implementation experience of real SQL engines, I'm extremely skeptical compatibility is actually possible without it being designed in from the start
325. # [07:42] <jwalden> and also, the wealth of SQL engines out there doesn't make it "in a vacuum" in my book
326. # [07:42] <jwalden> granted, not breathable air, but not top-of-Everest either
327. # [07:42] <jwalden> or rather not comfortably-breathable air
328. # [07:43] <crschmidt> http://crschmidt.net/mapping/localdb/
329. # [07:43] <crschmidt> Uses Google Gears or HTML5 Client storage
330. # [07:43] <crschmidt> to store the things you draw with the tools in the upper right
331. # [07:43] <crschmidt> (point, polygon, and modify tools)
332. # [07:43] <crschmidt> Drawings are saved every time you edit
333. # [07:44] <crschmidt> er, line, poly, and modify
334. # [07:51] <MikeSmith> crschmidt, nice
335. # [07:51] <MikeSmith> just tried it in Webkit
336. # [07:52] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
337. # [07:54] <crschmidt> MikeSmith: Cool.
338. # [07:55] <MikeSmith> crschmidt, I see you're involved with GIS applications.
339. # [07:56] <crschmidt> MikeSmith: Not that I'm aware of.
340. # [07:57] * Quits: roc (n=roc@202.0.36.64)
341. # [07:57] <MikeSmith> ? http://crschmidt.net/ says "GIS and Web Hacker"
342. # [07:58] <crschmidt> MikeSmith: Sorry, it's a joke that works with people who know me better :)
343. # [07:58] <crschmidt> I tend to be on the 'lunatic fringe' of gis
344. # [07:58] <crschmidt> living in the 'vulgar geography' world -- which a lot of people are loathe to refer to as GIS
345. # [08:01] <crschmidt> I had not realized that this was #whatwg when you said that
346. # [08:02] <MikeSmith> crschmidt, lunatic fringe sounds to me like a nice place to be
347. # [08:02] <MikeSmith> and vulgar geography sounds pretty intriguing
348. # [08:03] * MikeSmith writes that one down
349. # [08:03] <crschmidt> I enjoy living on the lunatic fringe, yes
350. # [08:03] * Joins: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
351. # [08:04] <crschmidt> If you're vaguely interested in geography and abuse of browsers to the end of exploring it, the 'choropleth' examples linked from http://crschmidt.net/mapping/ are good
352. # [08:04] <crschmidt> two in SVG, one in Canvas
353. # [08:05] <Hixie> jwalden: in practice so far everyone has used SQLite, so it may be easier to get interop than one may expect
354. # [08:05] <Hixie> jwalden: i honestly don't think the sql rabbit hole is gonna be any less deep than the html one, anyway
355. # [08:06] * crschmidt wonders who everyone is...
356. # [08:06] <crschmidt> Is there another implementation than Webkit that I should be checking this with?
357. # [08:06] <jwalden> and we really want to cover two holes the size of HTML?
358. # [08:07] <jwalden> and limiting to "the stuff sqlite supports" for determining what's interoperable does not a standard make
359. # [08:07] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
360. # [08:07] <Hixie> crschmidt: gears also has an implementation
361. # [08:07] <Hixie> crschmidt: and my understanding is that gecko may have one too? i forget
362. # [08:07] <crschmidt> Hixie: Okay, wasn't sure if that was the other one you were counting.
363. # [08:08] * MikeSmith takes a look at crschmidt examples
364. # [08:08] <Hixie> jwalden: it would be detailed
365. # [08:08] <crschmidt> FF3b5 doesn't have an openDatabase (or whatever) property
366. # [08:08] <Hixie> jwalden: we have to define this either way
367. # [08:08] <crschmidt> so if it's around, it's not in the FF3 branch so far as I can tell
368. # [08:08] <Hixie> i would be very surprised if this kind of thing was put into ff3
369. # [08:08] <jwalden> no, it's not in 3 or even implemented as a patch
370. # [08:09] <Hixie> oh right, i'm thinking of postMessage
371. # [08:09] * crschmidt couldn't find anything that indicated any support in FF or Opera
372. # [08:10] <MikeSmith> crschmidt, yeah, no support yet in FF or Opera
373. # [08:10] <MikeSmith> as far as your examples, they're great but I was expecting something more vulgar
374. # [08:10] <MikeSmith> please inject some vulgarity into them
375. # [08:11] <crschmidt> MikeSmith: 'vulgar geography' means 'gis that people who do GIS would swear at'
376. # [08:11] <crschmidt> Nothing is particularly vulgar about it in and of itself
377. # [08:14] <jwalden> Hixie: I disagree, at least as part of HTML5; defining an interoperable SQL syntax is going to be at least a hundred or so pages, well worth being put in its own spec, and well worth not being in HTML5 now as it distracts from the goal of specifying HTML as it exists, with small to medium-sized additions as needed
378. # [08:14] <jwalden> but you already knew that
379. # [08:14] <jwalden> and we're probably going to get nowhere on this
380. # [08:15] <Hixie> jwalden: i agree that it should be in tits own spec
381. # [08:16] <Hixie> jwalden: but if i'm the one who ends up speccing it, i basically have to put it in html5, as the overhead of editing another spec is extremely high
382. # [08:16] <Hixie> i wish we had more editors available
383. # [08:16] <Hixie> there's so much that needs to be taken out of html5
384. # [08:16] <Hixie> setTimeout, for instance
385. # [08:17] <Hixie> (i disagree that they distract, though, the platform is a single platform regardless of how many documents define it)
386. # [08:18] * Quits: sverrej_ (n=sverrej@89.10.27.86) (Read error: 110 (Connection timed out))
387. # [08:22] <MikeSmith> Hixie, editorial, r1439
388. # [08:23] <MikeSmith> [[+ being used as a glossary. Note the user of <code><a
389. # [08:23] <MikeSmith> + href="#dfn">dfn</a></code> to indicate the word being defined.</p>
390. # [08:23] <MikeSmith> ]]
391. # [08:23] <MikeSmith> should be "note the usage of" ? instead of "user"
392. # [08:23] <Hixie> oops
393. # [08:23] <Hixie> s/user/use/
394. # [08:23] <Hixie> will fix thanks
395. # [08:24] <Hixie> where's gsnedders
396. # [08:24] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
397. # [08:31] * Joins: heycam (n=cam@210-84-23-247.dyn.iinet.net.au)
398. # [08:32] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
399. # [08:32] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
400. # [08:33] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Remote closed the connection)
401. # [08:44] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
402. # [08:47] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
403. # [08:53] * Joins: KevinMarks (n=KevinMar@204.50.106.84)
404. # [08:58] * Joins: jruderman (n=jruderma@c-67-180-174-213.hsd1.ca.comcast.net)
405. # [09:01] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
406. # [09:10] * Quits: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
407. # [09:11] * Joins: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
408. # [09:23] * Quits: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
409. # [09:25] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
410. # [09:28] * bradee-oh is now known as bradee-slumbers
411. # [09:33] * Quits: jwalden (n=waldo@STRATTON-FOUR-SIXTY-NINE.MIT.EDU) (Remote closed the connection)
412. # [09:33] * Joins: gsnedders (n=gsnedder@host217-44-37-113.range217-44.btcentralplus.com)
413. # [09:36] * Joins: tndH_ (n=Rob@adsl-87-102-38-69.karoo.KCOM.COM)
414. # [09:37] * tndH_ is now known as tndH
415. # [09:47] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
416. # [09:52] * Joins: mpt (n=mpt@nat/canonical/x-a2932321f8016543)
417. # [10:01] * Joins: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
418. # [10:10] * Joins: ROBOd (n=robod@89.122.216.38)
419. # [10:15] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
420. # [10:17] * Quits: MikeSmith (n=MikeSmit@dhcp-247-165.mag.keio.ac.jp) (Read error: 110 (Connection timed out))
421. # [10:41] * Joins: MikeSmith (n=MikeSmit@EM60-254-197-254.pool.e-mobile.ne.jp)
422. # [10:45] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
423. # [10:47] * Joins: webben (n=benh@nat/yahoo/x-ca7457a0ed688646)
424. # [10:57] * Quits: Lachy_ (n=Lachlan@ti200710a340-2662.bb.online.no) ("This computer has gone to sleep")
425. # [10:59] * Joins: qwert666 (n=qwert666@acav178.neoplus.adsl.tpnet.pl)
426. # [11:08] * Joins: Lachy_ (n=Lachlan@pat-tdc.opera.com)
427. # [11:08] * Quits: KevinMarks (n=KevinMar@204.50.106.84) ("The computer fell asleep")
428. # [11:15] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
429. # [11:16] * Quits: Thezilch (n=fuz007@cpe-76-170-22-23.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
430. # [11:26] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
431. # [11:28] <hsivonen_> does <img aria-describedby='...'> do useful things in current implementations?
432. # [11:30] * Joins: KevinMarks (n=KevinMar@162.sub-75-210-250.myvzw.com)
433. # [11:31] * Quits: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
434. # [11:32] * Quits: MikeSmith (n=MikeSmit@EM60-254-197-254.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
435. # [11:33] <hsivonen_> is what the spec now says about <base> the whole story?
436. # [11:34] <hsivonen_> so are subsequent <base> elements ignored as far as later URI resolution goes?
437. # [11:34] <hsivonen_> so a Note says...
438. # [11:35] <annevk> "User agents must use the value of the href attribute of the first base element that is both a child of the head element and has an href attribute, if there is such an element, as the document entity's base URI for the purposes of section 5.1.1 of RFC 3986 ("Establishing a Base URI": "Base URI Embedded in Content")."
439. # [11:36] <hsivonen_> and then there's the xml:base stuff
440. # [11:36] <annevk> yes
441. # [11:36] <hsivonen_> so if <html> has xml:base, I have to reresolve the base URI stack upon seeing <base>
442. # [11:37] <annevk> that depends on whether the one on <html> is relative or not
443. # [11:37] <hsivonen_> well it can be, so...
444. # [11:46] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
445. # [11:48] * hsivonen_ isn't a big fan of xml:base
446. # [11:48] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
447. # [11:49] <annevk> most people are no fan
448. # [11:49] <annevk> why do you care though?
449. # [11:51] <hsivonen_> annevk: If I add features that involve resolving <img src>
450. # [11:51] <Lachy_> hsivonen_, as of IE7, only the first <base> element is used http://blogs.msdn.com/ie/archive/2005/08/29/457667.aspx
451. # [11:52] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
452. # [11:54] <annevk> hsivonen_, ah true, xml:base and <base> can now be used together
453. # [12:01] * Quits: kfish (n=conrad@61.194.21.25) ("Pike!")
454. # [12:10] <hsivonen_> what should happen if the base uri is a data uri?
455. # [12:10] <hsivonen_> when resolving a relative uri that is
456. # [12:12] <annevk> http://www.ietf.org/rfc/rfc3986 should tell in theory
457. # [12:12] <Philip`> Hopefully the same as clicking the link in data:text/html,<a href=foo.html>foo</a>
458. # [12:12] <Philip`> (but that varies between browsers quite significantly)
459. # [12:13] * Joins: hasather_ (n=hasather@90-231-107-133-no62.tbcn.telia.com)
460. # [12:13] <hsivonen_> for added fun, base64 can produce '/' in the data uri
461. # [12:13] <hsivonen_> (as can not using base64, of course)
462. # [12:14] <Lachy_> oh no, the b/i debate is starting up again :-(
463. # [12:15] <Lachy_> and Tina has come back
464. # [12:25] <othermaciej> I thought she was gone for good!
465. # [12:26] <hsivonen_> the thread was CCed to www-html
466. # [12:28] * Quits: heycam (n=cam@210-84-23-247.dyn.iinet.net.au) ("bye")
467. # [12:35] * Joins: heycam (n=cam@210-84-23-247.dyn.iinet.net.au)
468. # [12:43] * maikmerten is now known as maik|eat
469. # [12:45] * Quits: KevinMarks (n=KevinMar@162.sub-75-210-250.myvzw.com) ("The computer fell asleep")
470. # [12:48] * Joins: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
471. # [12:54] * Lachy_ is now known as Lachy
472. # [13:04] * Joins: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
473. # [13:06] * Quits: webben (n=benh@nat/yahoo/x-ca7457a0ed688646)
474. # [13:12] <hsivonen_> is there other inherited data I am not thinking in addition to base URI and language?
475. # [13:21] <hsivonen_> Hixie: any plans of supporting <meta http-equiv=content-language> as going in between HTTP and root lang?
476. # [13:21] <hsivonen_> Hixie: what about meta content-location vs. base?
477. # [13:24] <annevk> content-language might make sense
478. # [13:24] <annevk> content-location is not supported currently
479. # [13:24] <hsivonen_> annevk: ok.
480. # [13:24] <hsivonen_> I'll implement content-language while at it, then
481. # [13:26] <annevk> oh, the issue tracker is below 3000, even when private e-mails are included
482. # [13:26] <Philip`> (http://www.cl.cam.ac.uk/~pjt47/misc/attributes.html 'meta http-equiv' suggests that <meta http-equiv=content-language> is pretty popular)
483. # [13:27] <Philip`> (Also it suggests that <meta lang> is quite popular...)
484. # [13:27] <hsivonen_> base uri tracking is the hard part
485. # [13:28] <hsivonen_> lang tracking comes almost for free on top of that
486. # [13:30] <Philip`> (<meta name="author"lang="fr"en"content=betty savastano"> - ouch)
487. # [13:31] <Philip`> (http://www.floorball-linkpage.com/index.php - are you meant to be able to use keywords and lang like that?)
488. # [13:32] <annevk> I've seen that advocated in tutorials when I started learning HTML.
489. # [13:33] <annevk> Given that HTML does not do two languages at the same typically it's probably not "ok" altough it seems kind of logical...
490. # [13:37] * maik|eat is now known as maikmerten
491. # [13:46] * Quits: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
492. # [13:47] * Joins: tor_ (n=tor@cpe-24-28-29-26.austin.res.rr.com)
493. # [13:53] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
494. # [14:22] * Joins: webben (n=benh@nat/yahoo/x-26f1845efd175803)
495. # [14:34] * Quits: heycam (n=cam@210-84-23-247.dyn.iinet.net.au) ("bye")
496. # [14:41] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
497. # [14:41] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Client Quit)
498. # [14:41] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
499. # [14:42] * Joins: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp)
500. # [14:49] <zcorpan> BenMillard, hsivonen_: fyi, there's #wai-aria on irc.w3.org:6665 for public aria chat
501. # [14:55] * hsivonen_ is now known as hsivonen
502. # [14:56] * mpt wishes <input type="reset image"> was possible without scripting
503. # [14:57] <hsivonen> mpt: what do you need reset for? isn't reset almost always a usability bug?
504. # [14:58] <Lachy> woah, the SVG working group is requesting that we remove SVG from text/html
505. # [15:00] <hsivonen> Lachy: sigh. the message misses the point in ways that have already been explained
506. # [15:02] <mpt> hsivonen, it used to be, but not so much with XmlHttp I think
507. # [15:02] <Lachy> it's not clear to me from his message, which syntactic features they don't approve of.
508. # [15:03] <zcorpan> is my inbox slow or is this somewhere where i'm not subscribed?
509. # [15:03] <Lachy> zcorpan, it's on public-html
510. # [15:03] <Lachy> http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A3943CF3BF4@mailkeeper.mdigitalm.com
511. # [15:03] * Joins: heycam (n=cam@210-84-23-247.dyn.iinet.net.au)
512. # [15:04] <mpt> hsivonen, if you use Facebook, imagine that the "cancel" link when changing your status was an image.
513. # [15:05] * Quits: tndH (n=Rob@adsl-87-102-38-69.karoo.KCOM.COM) ("ChatZilla 0.9.81-rdmsoft [XULRunner 1.8.0.9/2006120508]")
514. # [15:08] <zcorpan> mpt: <input type=reset style=content:url(cancel.png)>
515. # [15:10] <hsivonen> mpt: I don't use Facebook, but why do you expect type=reset instead of type=button with XHR?
516. # [15:11] * Parts: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
517. # [15:11] <myakura> doesn't <button type=reset><img ...></button> work?
518. # [15:13] <mpt> myakura, it does, if limiting the button styling to the CSS that the browser allows (sometimes limited, sometimes none) is appropriate
519. # [15:14] <myakura> hmm
520. # [15:16] <mpt> hsivonen, the wrongness of type="reset" was that it reset your entire form, and then left you on the same page. With XHR leaving you on the same page is a goal, not a problem, and here I'm just wanting to cancel the modification of a single text field, or menu, where you might not remember what the initial value was.
521. # [15:17] <mpt> type="button" works, but it requires scripting, when all I want to do is reset this single-field form.
522. # [15:20] <annevk> i'm not sure if reset-image is the solution though, fixing browsers to allowing styling might be better
523. # [15:23] <mpt> Perhaps.
524. # [15:24] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
525. # [15:28] * myakura wonders that defining handling rules for text/html means changing the syntax
526. # [15:30] <myakura> re the mail which svg wg sent
527. # [15:30] <hsivonen> myakura: some byte streams would be valid SVG-in-text/html but not SVG-in-XML
528. # [15:31] <Philip`> Some other byte streams would be invalid SVG-in-text/html but would still work in text/html but not in XML
529. # [15:33] * Joins: csarven (n=csarven@on-irc.csarven.ca)
530. # [15:34] <myakura> hmm
531. # [15:37] <zcorpan> some other byte streams would be valid SVG-in-XML but wouldn't work in text/html
532. # [15:37] <zcorpan> (like usage of dtd internal subset or prefixes)
533. # [15:40] <hsivonen> <span lang='en'><span lang='***'>Is this English or undefined?</span></span>?
534. # [15:42] <Philip`> hsivonen: Passing that text through my standard language detection heuristics gives a strong confidence in it being English
535. # [15:43] <zcorpan> hsivonen: "To determine the language of a node, user agents must look at the nearest ancestor element (including the element itself if the node is an element) that has an xml:lang attribute set or is an HTML element and has a lang attribute set. That attribute specifies the language of the node."
536. # [15:43] <zcorpan> hsivonen: so the language is ***
537. # [15:44] <annevk> yeah, per current definitions it's ***
538. # [15:48] <hsivonen> thanks. time to send email, I guess
539. # [15:50] <Lachy> should the spec specify that if the value of the lang attribute isn't a valid language code, it is ignored and the language is inherited from its parent?
540. # [15:51] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
541. # [15:54] <hsivonen> Lachy: or that if it isn't a valid language code, it means the same as lang=''
542. # [15:54] * Lachy checks what lang='' is defined to mean...
543. # [15:55] <Lachy> ah, it means "Setting the attribute to the empty string indicates that the primary language is unknown."
544. # [16:07] * Joins: phsiao (n=shawn@c-71-233-78-251.hsd1.ma.comcast.net)
545. # [16:09] * Joins: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
546. # [16:12] * Quits: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net) (Client Quit)
547. # [16:13] * Joins: Camaban_ (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk)
548. # [16:13] * Joins: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
549. # [16:13] * Quits: phsiao (n=shawn@c-71-233-78-251.hsd1.ma.comcast.net)
550. # [16:13] * Quits: Camaban (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk) (Read error: 104 (Connection reset by peer))
551. # [16:15] * Quits: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net) (Client Quit)
552. # [16:26] * Joins: billmason (n=billmaso@ip200.unival.com)
553. # [16:28] * Quits: billmason (n=billmaso@ip200.unival.com) (Read error: 104 (Connection reset by peer))
554. # [16:29] * Quits: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
555. # [16:31] * Joins: billmason (n=billmaso@ip200.unival.com)
556. # [16:33] * Quits: Camaban_ (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk) (Read error: 104 (Connection reset by peer))
557. # [16:35] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
558. # [16:36] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
559. # [16:37] * Joins: phsiao (n=shawn@nat/ibm/x-170de2ddad75b8c4)
560. # [16:40] * Joins: eseidel (n=eseidel@nat/google/x-523638440722a190)
561. # [16:42] * Quits: phsiao (n=shawn@nat/ibm/x-170de2ddad75b8c4)
562. # [16:49] * Joins: qwert666_ (n=qwert666@acag9.neoplus.adsl.tpnet.pl)
563. # [16:50] * Joins: aroben (n=aroben@unaffiliated/aroben)
564. # [16:55] * Joins: phsiao (n=shawn@nat/ibm/x-b47b9ee27f6235d4)
565. # [17:07] * Quits: qwert666 (n=qwert666@acav178.neoplus.adsl.tpnet.pl) (Read error: 110 (Connection timed out))
566. # [17:17] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
567. # [17:24] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
568. # [17:24] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
569. # [17:39] <annevk> http://www.w3.org/QA/2008/04/proposed_activity_for_video_on.html ...
570. # [17:41] * Joins: Lachy (n=Lachlan@ti200710a340-2662.bb.online.no)
571. # [17:42] <hsivonen> still missing the most important expected outcome of the workshop :-(
572. # [17:46] <Philip`> Is the expected outcome that they won't find a suitable codec, because the video world is evil and full of patents?
573. # [17:47] <hsivonen> heh
574. # [17:47] <hsivonen> I meant finding a codec
575. # [17:48] <annevk> The proposed WGs seem boring and it's really unfortunate they don't say anything about the codec issues...
576. # [17:56] * Joins: webben_ (n=benh@nat/yahoo/x-970939bb2ad901cc)
577. # [17:57] * Quits: webben (n=benh@nat/yahoo/x-26f1845efd175803) (Read error: 104 (Connection reset by peer))
578. # [18:06] * Quits: tor_ (n=tor@cpe-24-28-29-26.austin.res.rr.com) (Read error: 110 (Connection timed out))
579. # [18:06] * Quits: annevk (n=annevk@77.163.243.203) (Read error: 104 (Connection reset by peer))
580. # [18:07] * Joins: annevk (n=annevk@77.163.243.203)
581. # [18:12] * Joins: weinig (n=weinig@adsl-76-200-102-233.dsl.pltn13.sbcglobal.net)
582. # [18:15] * Joins: tor_ (n=tor@nat/ibm/x-92c69be888ca0206)
583. # [18:17] <mpt> Is the Sun thing years too late?
584. # [18:17] <hsivonen> mpt: the Sun thing?
585. # [18:18] <mpt> http://www.pcworld.com/businesscenter/article/144494/sun_tackles_video_codec.html
586. # [18:18] <Philip`> It's been here for five billion years already, so I wouldn't call it late
587. # [18:18] <mpt> har har
588. # [18:18] <hsivonen> interesting
589. # [18:19] <gsnedders> They are a big enough company for submarines, at least
590. # [18:20] <mpt> ("Since the beginning of time, submarines have yearned to destroy the Sun!")
591. # [18:20] <Philip`> Might be interesting to see what they've done five years from now
592. # [18:21] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) ("Ex-Chat")
593. # [18:21] <mpt> Ah, they are intending it specifically with HTML's problem in mind
594. # [18:21] <mpt> http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of
595. # [18:21] <Philip`> (I guess it'll take a while to develop it, and they'll write all their software in Java, so it'll take a while longer for someone sensible to write a decent C implementation, and then maybe it'd be useful)
596. # [18:22] <Philip`> Their mentions of H.261 sound kind of worrying, given how rubbish H.261 is
597. # [18:24] <mpt> OMS Video isn't actually mentioned on <http://www.openmediacommons.org/projects.html> (yet?) though
598. # [18:24] * bradee-slumbers is now known as bradee-oh
599. # [18:24] <hsivonen> Philip`: h.264 comes from the 'rubbish' lineage, too
600. # [18:26] <Philip`> hsivonen: H.264 has had another ~15 years of evolution, which should be around a 1000 times increase in computer power and a huge amount more experience
601. # [18:27] <hsivonen> worse, it means that some of the useful evolutionary paths are patented
602. # [18:27] <Philip`> I imagine many of the non-useful paths are patented too
603. # [18:28] <mpt> (For the benefit of archive readers: I'm all in favor of free codecs. If Sun can make one successful, go Sun.)
604. # [18:29] <Philip`> It looks kind of like they're taking the SQLite approach and avoiding any techniques that haven't been published long enough ago for patents to have expired
605. # [18:30] <Philip`> (I'm in favour of anything that anybody does that's successful :-) )
606. # [18:30] <gsnedders> Vorbis did that, and is still competitive. I'm wondering whether that's doable with video, thoguh
607. # [18:30] <gsnedders> The longer the video issue goes on, the more I doubt it is a realistic aim
608. # [18:30] <gsnedders> (though, FWIW, I'd love to be proved wrong)
609. # [18:31] <Philip`> gsnedders: I don't think I've ever heard that Vorbis limited themselves to old techniques - they just used unpatented ones, and did patent searches to be more confident they hadn't missed some
610. # [18:31] <Philip`> (or at least that's what I think they did)
611. # [18:31] <mpt> gsnedders, because learning more about it makes you more pessimistic, or because the mere passage of time makes it less likely?
612. # [18:32] <gsnedders> mpt: the more I learn the more pessimistic I become, and I doubt time will do much to help
613. # [18:33] * Joins: andersca (n=andersca@nat/apple/x-d1db9c1d891e3810)
614. # [18:37] <annevk> i applaud any initiative that gives us RF video
615. # [18:39] <hsivonen> I wonder what Sun's lawyer make of Diract
616. # [18:39] <hsivonen> Dirac
617. # [18:47] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
618. # [18:50] * Quits: eseidel (n=eseidel@nat/google/x-523638440722a190)
619. # [18:53] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
620. # [18:54] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
621. # [18:57] <Lachy> Adobe is also working on a free video codec called CinemaDNG http://blog.wired.com/monkeybites/2008/04/adobe-cinemadng.html
622. # [18:57] <Lachy> though it appears to be a capture format, rather than a publishing format
623. # [18:59] <Lachy> I'm not so sure about sun's new codec though. I'm hoping dirac will eventually succeed, though, realistically, h.264 will be around for quite a few years regardless
624. # [19:00] <Lachy> the ideal situation would be for h.264 to become royalty free
625. # [19:00] <othermaciej> Adobe's thing seems to be a raw video codec
626. # [19:00] <othermaciej> We will see if Sun
627. # [19:00] <Lachy> othermaciej, yes
628. # [19:00] <othermaciej> 's thing becomes anything more than talk
629. # [19:01] <othermaciej> I am unimpressed with the "press release first, code later" approach so far though
630. # [19:01] * Quits: weinig (n=weinig@adsl-76-200-102-233.dsl.pltn13.sbcglobal.net)
631. # [19:08] <Philip`> Lachy: Given how long it seems to have taken for H.264 to take off, I guess any new codec will similarly take a long time before becoming popular
632. # [19:09] <Philip`> (I think I've only noticed people using H.264 seriously in the past couple of years)
633. # [19:11] * Joins: eseidel (n=eseidel@nat/google/x-ee17d8706f9b896d)
634. # [19:12] <othermaciej> H.264 has seen significant non-web use for a long time
635. # [19:15] <Hixie> Lachy: dirac is more of an archival format, not really appropriate for web use
636. # [19:15] <Hixie> as i understand it
637. # [19:15] * Parts: crschmidt (i=crschmid@bia.crschmidt.net)
638. # [19:17] <annevk> "It was presented by the BBC in January 2004 as the basis of a new codec for the transmission of video over the Internet."
639. # [19:17] <annevk> -- http://en.wikipedia.org/wiki/Dirac_(codec)
640. # [19:17] <othermaciej> it has not been presented that way lately
641. # [19:18] <Lachy> I thought it was designed to be comparable with h.264 in compression and quality
642. # [19:18] <hsivonen> has anyone seen Dirac in action?
643. # [19:18] <hsivonen> the VC-2 profile dropped inter-frame compression, IIRC
644. # [19:19] * Quits: eseidel (n=eseidel@nat/google/x-ee17d8706f9b896d)
645. # [19:20] <annevk> Everything on that Wikipedia page sounds like it could be used today... I guess some information is missing.
646. # [19:21] <Lachy> "the reference implementation can decode around 17 frames per second [in PAL SD] on a 3 GHz PC" - that seems a bit slow
647. # [19:22] * Philip` tries "emerge dirac" and wonders what it will install
648. # [19:22] * annevk thanks Hixie for resurfacing such classics as 'it would only be useful for the few who "love semantics"'
649. # [19:23] * Joins: KevinMarks (n=KevinMar@132.sub-75-221-221.myvzw.com)
650. # [19:23] * Joins: eseidel (n=eseidel@nat/google/x-4dd74f8ea84b73c3)
651. # [19:25] <takkaria> Lachy: yeah, they're only just getting round to optimising playback
652. # [19:26] * Quits: eseidel (n=eseidel@nat/google/x-4dd74f8ea84b73c3) (Client Quit)
653. # [19:27] <Lachy> takkaria, yeah, I know, but still, that's quite slow for only standard definition. I want to be able to play video at 1080p/50 or 60fps
654. # [19:28] <Lachy> and I want it streamed over the web in real time :-)
655. # [19:28] <annevk> just make sure you enable your time machine while browsing and you'll be fine
656. # [19:28] <jmb> I wonder if there's any information for schrodinger's decode performance
657. # [19:28] <Philip`> And you want to pay $20/month to your ISP for bandwidth?
658. # [19:29] * Philip` attempts encoding a video with dirac_encoder
659. # [19:29] <annevk> "On 22nd of February 2008, Schrödinger 1.0.0 was released. This release was able to decode HD720/25p in real-time on a Core Duo laptop."
660. # [19:31] <Lachy> I wonder how that compares with the requirements for h.264 at 720p/25
661. # [19:32] * Quits: csarven (n=csarven@on-irc.csarven.ca) (Read error: 113 (No route to host))
662. # [19:32] <othermaciej> I have a Core Duo laptop and H.264 capability but I wouldn't know where to find standard test videos of various frame rates
663. # [19:32] <jmb> annevk: aha. that'll teach me to ask questions before reading the wiki page :) I note that the schroedinger website is utterly silent about its performance
664. # [19:32] * Joins: csarven (n=csarven@on-irc.csarven.ca)
665. # [19:32] * Philip` fails at encoding a video
666. # [19:33] <Lachy> I can't figure out Vlad's definition of "web content" http://html4all.org/mailman/archives/list_html4all.org/2008-April/000731.html
667. # [19:34] <Lachy> even his explanation makes no sense http://html4all.org/mailman/archives/list_html4all.org/2008-April/000733.html
668. # [19:35] <annevk> Maybe he's looking for some definition that validates his practices...
669. # [19:36] <Lachy> my definition of "web content" would be any content delivered over the web, no matter how it is used
670. # [19:37] <hsivonen> I consider Joshue O'Connor's videos Web content even though they only had an Apache-generated directory listing linking to them, IIRC.
671. # [19:41] <annevk> "Web content is something made with my software, damn't!"
672. # [19:41] <Hixie> you can put anything on the web
673. # [19:42] <mpt> I prefer Web discontent
674. # [19:42] <mpt> It's much more interesting
675. # [19:42] <Hixie> what makes a format technically appropriate is a few characterstics, including relatively trivial seeking, streamability with synchronised sound and video, good compression characteristics, a data stream that is resistant to dropped packets, etc.
676. # [19:43] <hsivonen> dropped packet resilience doesn't help on http
677. # [19:43] <hsivonen> some video formats are over-resient to transport problems
678. # [19:43] <hsivonen> since the lower abstraction takes care of stuff
679. # [19:44] * Quits: jruderman (n=jruderma@c-67-180-174-213.hsd1.ca.comcast.net)
680. # [19:44] <Hixie> the svg working group didn't even cc their own lists on their request
681. # [19:45] <Hixie> sheesh
682. # [19:45] * Hixie removes SVG from text/html
683. # [19:45] <takkaria> noooo
684. # [19:46] <Hixie> hey if the svg working group wants to shoot itself in the head, i'm not going to stop them
685. # [19:46] <hsivonen> Hixie: SVG now has other stakeholders in addition to the WG
686. # [19:46] <Hixie> the longer we delay the sudden expansion phase of svg on the web, the longer i have to go in and actually do a proper job fixing it
687. # [19:47] <hsivonen> Hixie: just like HTML had other stakeholders during the time when its orinator no longer considered it viable
688. # [19:47] <Hixie> they'll probably take at least two years to get back to us, at which point i might have more free time to work on svg5
689. # [19:47] <Philip`> dirac_decoder takes me 3.6 seconds for 150 frames at 320x240, on a C2D 2.0GHz
690. # [19:47] <mpt> ding!
691. # [19:48] <Philip`> (for a 1MB input file)
692. # [19:49] <hsivonen> the WCAG 2.0 definitions are probably too abstact for normal authors to grok
693. # [19:54] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
694. # [19:56] <Philip`> Hmm, Dirac 0.9.1 at 256Kbps on 320x240x30fps seems kind of roughly comparable quality to MPEG-2 (except blurry instead of blocky), and significantly worse than H.264
695. # [19:57] <Philip`> (Theora seems much closer to H.264)
696. # [19:58] <Philip`> (though all the encoders are really rubbish at getting the requested bitrate, so my comparisons are very unfair)
697. # [20:00] * Quits: KevinMarks (n=KevinMar@132.sub-75-221-221.myvzw.com) ("The computer fell asleep")
698. # [20:04] <gsnedders> Philip`: Dirac, AFAIK, is more or less totally unoptimised to this day
699. # [20:05] * Joins: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net)
700. # [20:05] <Philip`> gsnedders: Do you mean runtime performance, or compression quality? (or both?)
701. # [20:05] <gsnedders> Philip`: both
702. # [20:06] <gsnedders> Philip`: the point up to the release of 1.0 of the specs was having an codec that _worked_, regardless of performance
703. # [20:06] * Joins: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
704. # [20:07] <Philip`> gsnedders: It's trivial to make a codec that works - just replace dirac_encoder and dirac_decoder with 'cat'
705. # [20:07] <gsnedders> Philip`: that doesn't isn't actually a encoder/decoder :P
706. # [20:07] <Philip`> gsnedders: Then use base64 instead
707. # [20:07] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
708. # [20:07] <gsnedders> Philip`: :P
709. # [20:07] <Philip`> or if you want to be fancy and insist on compression, use gzip
710. # [20:08] <hsivonen> if I'm displaying an image and its alt for review, what HTML markup should I use?
711. # [20:09] <hsivonen> Clearly, I'm having list items
712. # [20:09] <gsnedders> Is it not a table of images and alternatives?
713. # [20:10] <hsivonen> gsnedders: it could be
714. # [20:10] <gsnedders> It seems like tabular data to me.
715. # [20:10] <hsivonen> I want to put source locations there, too
716. # [20:10] <Philip`> The list is defining the alt values for the images, so use <dl>
717. # [20:10] <gsnedders> actually, it's a perfect example of when we have an image that is significant content that cannot have any textual alternative
718. # [20:11] <hsivonen> Philip`: would I put source location in <dd>, too?
719. # [20:11] <Philip`> Or just use <br>
720. # [20:11] <Philip`> hsivonen: I guess that wouldn't quite work sensibly
721. # [20:12] <hsivonen> I probably want the image on the left and the alt and the location on the right with the alt above the location
722. # [20:13] <hsivonen> or image on the right and location and alt on the left
723. # [20:13] <hsivonen> also, the list should have reasonably similar layout for cases with no alt
724. # [20:13] <Philip`> <img align=left>alt<br>location<br clear=both>
725. # [20:14] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
726. # [20:17] <hsivonen> or <li><p style='display:table-cell'><img></p><div style='display:table-cell'><p>alt</p><p>location</p></div></li>
727. # [20:29] * Joins: eseidel (n=eseidel@nat/google/x-3b3faa1fa3e49b54)
728. # [20:29] * Quits: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
729. # [20:32] * Joins: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
730. # [20:36] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
731. # [20:46] <annevk> Hixie, the statement about SVG is not gone... http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#svg
732. # [20:48] <Hixie> ah, indeed not
733. # [20:48] <Hixie> i forgot that i decided it would be useful in xhtml anyway
734. # [20:49] * annevk assumed it was for text/html + DOM
735. # [20:50] * Quits: eseidel (n=eseidel@nat/google/x-3b3faa1fa3e49b54)
736. # [20:51] <Hixie> that use case isn't going to happen enough for the spec to suggest UI for it :-)
737. # [20:52] * Quits: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
738. # [20:53] <annevk> the longer there's no syntax, the more libraries will create exactly that :)
739. # [20:56] * Joins: othermaciej (n=mjs@17.203.15.181)
740. # [20:59] <Hixie> like i said
741. # [20:59] <Hixie> if they want to shoot themselves in the head...
742. # [20:59] <Hixie> who am i to stop them
743. # [20:59] <Hixie> especially when they ask so kindly
744. # [21:00] <hsivonen> are these photos sufficiently textually accompanied: http://flickr.com/photos/18356286@N00/ ?
745. # [21:00] <annevk> talking about graphics, http://lists.w3.org/Archives/Public/public-canvas-api/ seems like a big hit :)
746. # [21:00] <Dashiva> Hixie: I usually avoid helping such people, because I know they'll get my clothes dirty in the process
747. # [21:01] <Hixie> hsivonen: "it's unfair to expect _me_ to do what i preach"
748. # [21:01] <Hixie> Dashiva: well you'll notice the changes to the spec were minimal and easily reversible
749. # [21:02] <Hixie> Dashiva: if necessary, whatwg's version could easily revert :-)
750. # [21:03] * Joins: eseidel (n=eseidel@nat/google/x-e57b965d3ebb4fae)
751. # [21:03] <Lachy> Wouldn't it be more useful for the current SVG proposal to remain in the spec, and for the SVG working group to suggest specific changes as required, instead of pulling it out and starting from scratch?
752. # [21:03] <Dashiva> Here's hoping for a good resolution
753. # [21:03] * Quits: eseidel (n=eseidel@nat/google/x-e57b965d3ebb4fae) (Client Quit)
754. # [21:04] <hsivonen> Lachy: it would. there's collateral damage when SVG WG is allowed to shoot self
755. # [21:04] <annevk> Having WHATWG conditionals for something as trivial as SVG syntax seems bad...
756. # [21:05] <Hixie> did jf just say that inaccessible images on an ftp server were ok but inaccessible images on an http server were not?
757. # [21:05] <Hixie> or am i misunderstanding
758. # [21:05] <Hixie> Lachy: feel free to suggest it to them
759. # [21:05] <annevk> He did...
760. # [21:05] <Hixie> good good
761. # [21:06] <Lachy> I will
762. # [21:06] <annevk> My image collections are exactly that... They're just served over HTTP for convenience.
763. # [21:09] <hsivonen> I still don't have a good design for presentin repeating rows of image, alt, source location triplets :-(
764. # [21:09] <hsivonen> I want the images line up nicely
765. # [21:10] <hsivonen> and I want the alt to be near the image even if the window is wide
766. # [21:10] <hsivonen> Do I really need to put these in a table?
767. # [21:10] <Hixie> hsivonen: sounds like tabular data to me
768. # [21:10] <annevk> why not?
769. # [21:10] <annevk> img | alt | location
770. # [21:11] <Hixie> hsivonen: what you really want is the page itself, styled, and little text boxes appearing over the images or instead of the images as you hover over them, or some such
771. # [21:11] <hsivonen> annevk: table rows with an image and most often a single line of text looks ugly and unbalanced
772. # [21:11] <hsivonen> Hixie: yeah, this will be less contextual
773. # [21:11] <annevk> that's a CSS issue :)
774. # [21:12] <Lachy> hsivonen, display each image as a scaled/cropped thumbnail, so they're all the same size. Then, when an image is clicked, use the lightbox effect, or something similar, to display the full size iamge
775. # [21:12] <Lachy> *image
776. # [21:12] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
777. # [21:12] <hsivonen> Hixie: I'm aiming for a solution that I think has the upsides of checking for alt presence but not the downsides of making it part of the validation function and silencing messages when *some* alt is present
778. # [21:13] <hsivonen> what's the lightbox effect?
779. # [21:13] <Hixie> hsivonen: ah
780. # [21:13] <Lachy> hsivonen, http://www.huddletogether.com/projects/lightbox2/
781. # [21:14] * hsivonen sees no effect; tries different browser
782. # [21:15] <Lachy> that site seems to be broken now
783. # [21:15] <Lachy> FF reports a script error
784. # [21:15] <Lachy> this is an earlier version, but it works http://www.huddletogether.com/projects/lightbox/
785. # [21:16] <hsivonen> Lachy: that seems annoying
786. # [21:17] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
787. # [21:17] <hsivonen> I wonder if I could zoom the images on :hover (for users who have a hoverable pointing device) and :focus (for users who have no pointing device or a click-only pointing device)
788. # [21:19] * hsivonen wants a way to say width attribute times * 3 in CSS
789. # [21:20] <Dashiva> hsivonen: You could also show alt and location on top of each other, with image to the side
790. # [21:22] <hsivonen> Dashiva: yeah. layout tables ftw!
791. # [21:23] <Dashiva> Wouldn't need to be a table anymore! Since there's only one internal column border to align to, it can be done with just setting fixed width on the image :)
792. # [21:24] <hsivonen> Dashiva: with floats?
793. # [21:24] <hsivonen> Dashiva: or with display:table-cell?
794. # [21:24] <hsivonen> or something else?
795. # [21:24] <Dashiva> inline-block? :)
796. # [21:25] <hsivonen> Dashiva: do you mean putting the non-image stuff in an inline-block?
797. # [21:25] <Dashiva> Yeah
798. # [21:26] <hsivonen> what's the support status of inline-block these days?
799. # [21:26] <Dashiva> There's support in some firefox version, but I don't recall if it's 2 or 3
800. # [21:28] <hsivonen> I think I'll make a real data table for now
801. # [21:28] <Dashiva> rowspan on the image works too
802. # [21:29] * Joins: weinig (n=weinig@17.203.15.172)
803. # [21:34] * jgraham_ is glad to find that find that John Foliot is just as bewildering to others
804. # [21:34] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
805. # [21:35] * Joins: eseidel (n=eseidel@nat/google/x-6dd5c8ad4c5fb8cc)
806. # [21:42] <Hixie> i'm so sad that #css isn't publicly archived yet like the csswg resolved it to be
807. # [21:42] <othermaciej> why, was there something interesting on it?
808. # [21:45] <Philip`> Hixie: s/encouaraged/encouraged/ in that #svg text, unless it's just going to be deleted forever
809. # [21:45] <Hixie> fixed
810. # [21:47] <hsivonen> Hixie: your 'nobody' is not exactly correct. jf is suggesting replacing alt='' with something else
811. # [21:53] * Quits: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
812. # [21:53] * Joins: gavin__ (n=gavin@people.mozilla.com)
813. # [21:54] * Joins: heycam` (n=cam@124-168-30-80.dyn.iinet.net.au)
814. # [21:54] * Joins: svl_ (n=me@ip565744a7.direct-adsl.nl)
815. # [21:55] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) (brown.freenode.net irc.freenode.net)
816. # [21:55] * Quits: Hixie (i=ianh@trivini.no) (brown.freenode.net irc.freenode.net)
817. # [21:55] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (brown.freenode.net irc.freenode.net)
818. # [21:55] * svl_ is now known as svl
819. # [21:57] * Joins: Hixie (i=ianh@trivini.no)
820. # [22:00] <Dashiva> In the SVG mail it says "We are happy to make rapid progress on allowing SVG in text/html". Is that businessspeak for thinking it's a good idea, or is the SVG group actually working on text/html svg?
821. # [22:02] <annevk> "maximizing compatibility" "wide range"
822. # [22:03] <annevk> definitely sounds like marketese
823. # [22:03] * Quits: heycam (n=cam@210-84-23-247.dyn.iinet.net.au) (Read error: 101 (Network is unreachable))
824. # [22:04] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
825. # [22:08] * Joins: othermaciej_ (n=mjs@17.255.110.29)
826. # [22:08] * Joins: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
827. # [22:09] * Quits: othermaciej (n=mjs@17.203.15.181) (Nick collision from services.)
828. # [22:09] * othermaciej_ is now known as othermaciej
829. # [22:13] <hsivonen> argh. I forgot to support right-to-left alt
830. # [22:16] * Joins: sverrej (n=sverrej@89.10.27.86)
831. # [22:20] <Hixie> Lachy: i have a request here from someone suggesting the query-by-selectors api should apply to all NodeList objects too
832. # [22:23] * Quits: roc (n=roc@121-72-183-7.dsl.telstraclear.net)
833. # [22:30] <Lachy> Hixie, send mail about it.
834. # [22:31] <Lachy> I'm not sure I could get it into this first version of the spec, but it might be an interesting extension for the next revision
835. # [22:31] <Lachy> especially since we're starting to get implementations already, I'd rather focus on getting interop with the current feature set before piling on more
836. # [22:32] <annevk> how does it work on NodeList?
837. # [22:32] <Hixie> Lachy: already done
838. # [22:33] <Lachy> I assume it would evaluate each node in the list, in the context of the document it's in
839. # [22:33] <Dashiva> So it's more like using the nodelist as a filter to the query result
840. # [22:34] <Lachy> e.g. var list = document.getElementsByTagName("p"); var filteredList = list.querySelector("div>p");
841. # [22:34] <gsnedders> jgraham_: for my implementation of the outline algorithm, having looked at it quite closely, it seems it'll be easier for me to start from scratch
842. # [22:34] <Lachy> so filteredList would contain all the p elements from list, which are children of div elements in the document
843. # [22:34] <Lachy> not sure of the use case though, since document.querySelector("div>p"); would do the same
844. # [22:35] <Hixie> yeah i dunno what the use case is exactly, though there are other places that return NodeLists
845. # [22:35] <Hixie> i just want the issue off my plate :0D
846. # [22:35] <Philip`> Is something wrong with your nose?
847. # [22:36] * Joins: KevinMarks (n=KevinMar@209.139.210.235)
848. # [22:36] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
849. # [22:37] <Lachy> woah, you've had that on your plate since 23 Sep 2005.
850. # [22:37] <Hixie> possibly
851. # [22:37] <Lachy> I guess it's better late than never
852. # [22:37] <Hixie> Lachy: heh
853. # [22:37] <Hixie> Lachy: i've been replying to some of these e-mails dated 2004
854. # [22:38] <Lachy> I suppose that would have been sent before the webapi wg was formed, and thus hadn't begun working on selectors api.
855. # [22:38] <Dashiva> By making querySelector work on nodelists, it would be possible to chain querySelector calls too...
856. # [22:39] <Lachy> so that's why you wouldn't have forwarded it then
857. # [22:39] * hsivonen wonders why python os.path.getctime doesn't work on Mac OS X and HFS+
858. # [22:39] <Hixie> Lachy: yeah it ended up in the worng bucket
859. # [22:39] <Lachy> Dashiva, what's the point in chaining queryselector calls?
860. # [22:39] <hsivonen> it seems to run generic Unix code instead of Mac code
861. # [22:39] <Lachy> just chain the selctors and make one call
862. # [22:39] <annevk> the initial Selectors API draft was made in some hotel in Rabat
863. # [22:39] <Dashiva> Lachy: If you want to select something based on ancestors or preceding siblings, CSS isn't very helpful
864. # [22:40] <annevk> prolly end of 2006
865. # [22:40] <annevk> September 2x 2006 iirc
866. # [22:40] <Hixie> document.querySelector('a x').querySelector('b x') is equivalent to 'a b x, b a x' which can get much more complex
867. # [22:41] <Lachy> Dashiva, I assume you meant if you want to select ancestors or preceding siblings, rather than something based on those (since selectors already work the way you said it)
868. # [22:41] <Dashiva> Yeah, that
869. # [22:41] <Dashiva> And Hixie seems to have found an even better case :)
870. # [22:41] <Hixie> it's a bit like having :matches(... #)
871. # [22:42] <Lachy> oh, right
872. # [22:42] <Lachy> it's worth thinking about, but definitely need to evaluate the use cases and see how authors actually use these apis
873. # [22:43] * Quits: webben_ (n=benh@nat/yahoo/x-970939bb2ad901cc) (Read error: 104 (Connection reset by peer))
874. # [22:43] * Joins: webben (n=benh@nat/yahoo/x-45c8508ddef8755e)
875. # [22:43] * Quits: webben (n=benh@nat/yahoo/x-45c8508ddef8755e) (Remote closed the connection)
876. # [22:44] <Hixie> yup
877. # [22:46] <gsnedders> Oh dear. This really is broken.
878. # [22:47] * Joins: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
879. # [22:50] * Joins: csarven- (n=csarven@on-irc.csarven.ca)
880. # [22:50] <gsnedders> Anyone know of a decently performant NodeIterator in Python?
881. # [22:57] * gsnedders realises he can more or less just safely use getElementsByTagName("*") for what he needs
882. # [23:02] <Dashiva> The alt discussion is like an echo of echoes
883. # [23:04] * Joins: roc (n=roc@202.0.36.64)
884. # [23:06] * Joins: othermaciej_ (n=mjs@17.255.110.29)
885. # [23:06] * Quits: othermaciej (n=mjs@17.255.110.29) (Read error: 104 (Connection reset by peer))
886. # [23:08] <jgraham_> gsnedders: np. Is is just that my code is crap, or that it doesn't fit into your grand plan?
887. # [23:09] <gsnedders> jgraham_: I'd need to more or less rewrite it to fit into the algorithm as a whole
888. # [23:09] * Quits: othermaciej_ (n=mjs@17.255.110.29) (Read error: 104 (Connection reset by peer))
889. # [23:09] <gsnedders> (i.e., the latteR)
890. # [23:09] <jgraham_> (also, I may have mentioned, if you want performance in python and you're not using lxml yoyu've already lost :) )
891. # [23:09] * Joins: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com)
892. # [23:10] <gsnedders> With how stuff it going, it's becoming questionable whether I need DOM anymore
893. # [23:11] <gsnedders> jgraham_: That said, that isn't the bottleneck :)
894. # [23:11] * Joins: othermaciej (n=mjs@17.255.110.29)
895. # [23:11] <jgraham_> gsnedders: what's the bottleneck?
896. # [23:12] <gsnedders> jgraham_: html5lib tokenising is the biggest
897. # [23:12] <jgraham_> Oh. Well yeah html5lib sucks :)
898. # [23:12] <gsnedders> Only real way to make a big change with that is for it to be a Py extension
899. # [23:13] * jgraham_ decides to do some work on html5lib since no one seems interested in the alt text survey thing
900. # [23:13] <gsnedders> I may just give up on Python and write it in C++ (though with my total lack of knowledge of what's needed to write it that'd be hard)
901. # [23:14] <gsnedders> But that would be quick.
902. # [23:14] <jgraham_> gsnedders: Write what in C++?
903. # [23:14] <gsnedders> jgraham_: spec-gen
904. # [23:14] <Philip`> jgraham_: The problem with doing an alt text survey is that it would produce data, and so it might conflict with people's opinions
905. # [23:14] <jgraham_> gsnedders: Wouldn't it make sense to write a html parser in C(++) rather than the whole thing
906. # [23:15] <Philip`> Writing in C++ seems like probably not a great idea
907. # [23:15] <Philip`> particularly if you're doing things with strings and data structures
908. # [23:15] <jgraham_> Philip`: The thought had occurred to me
909. # [23:15] <gsnedders> jgraham_: peh. Once you've done the HTML parser part the rest is simple enough in any language, really
910. # [23:16] <gsnedders> (I'd just use WebKit's HTML/DOM stuff, to avoid reinventing the wheel there)
911. # [23:16] * Philip` was responding mostly to gsnedders
912. # [23:17] <jgraham_> gsnedders: I imagine it would be significantly easier to write the front end in a non-C based language
913. # [23:17] <jgraham_> Philip`: I meant about the survey
914. # [23:17] <Philip`> jgraham_: Oh
915. # [23:17] <Philip`> jgraham_: That makes sense, then - please ignore my comment :-)
916. # [23:17] <jgraham_> Although one possibility would be to write the string manipulation bits in javascript and make it run in a browser
917. # [23:18] <jgraham_> possibly from the command line
918. # [23:18] <Philip`> gsnedders: You won't say the rest is simple once you're trying to use a std::tr1::hash_map<std::string, std::pair<int, int> > just to do some simple processing that would take no lines of code in Python :-)
919. # [23:19] <gsnedders> Philip`: :)
920. # [23:20] <gsnedders> Philip`: all my experience of C based strings has probably been spoiled by OpenStep and Obj-C. :) That probably makes C++ look even worse :)
921. # [23:20] <Philip`> C++ strings work alright, as long as you don't care too much about Unicode, but it's not very concise at more complex data structures
922. # [23:21] <gsnedders> From what I've seen, WebKit handles strings quite nicely
923. # [23:22] <hsivonen> Philip`: how common is it for non-trivial apps to use C++ strings. the C++ code I've seen either uses C-style strings or custom string classes
924. # [23:23] <jgraham_> How common is it to use C-style strings? C-style strings seem a bit evil even in C...
925. # [23:23] <Philip`> gsnedders: Probably because they use a custom string class, which is more code you have to import into your own project and work out how to compile
926. # [23:23] <gsnedders> Philip`: that and C-style strings, but yeah
927. # [23:23] * jgraham_ has very little real experience here
928. # [23:24] <Philip`> hsivonen: How would you count custom string classes that inherit from C++'s std::string?
929. # [23:24] <hsivonen> jgraham_: very common, I'd say without quatitative evidence
930. # [23:24] <gsnedders> Philip`: But if I was using the HTML/DOM from it, I'd need it anyway
931. # [23:24] <annevk> hmm, I replied to a message about alt and Hixie just replied to the same...
932. # [23:24] * gsnedders really does need an actual NodeIterator, regardless
933. # [23:24] <annevk> oh well
934. # [23:24] <jgraham_> gsnedders: Write your own?
935. # [23:24] <hsivonen> Philip`: I don't know how I'd count those.
936. # [23:24] <gsnedders> jgraham_: I'm lazy, and busy :)
937. # [23:24] * Philip` has a non-trivial (100-200KLOC, I think) C++ program with a custom string class that inherits from std::string
938. # [23:25] <jgraham_> Or do it in a browser like I said
939. # [23:25] <jgraham_> or find a way to not need one :)
940. # [23:25] <hsivonen> Philip`: is the stl really 's' these days? Mozilla C++ bans a lot of stuff including the 'standards' libs
941. # [23:25] <gsnedders> jgraham_: that can't really be done through the CLI, though
942. # [23:26] <gsnedders> Mozilla reimplements the wheel, though :)
943. # [23:26] * Quits: othermaciej (n=mjs@17.255.110.29) (Read error: 110 (Connection timed out))
944. # [23:26] <jgraham_> gsnedders: I think you can run some browsers in windowless modes
945. # [23:26] * gsnedders ought to go sleep regardless
946. # [23:27] * jgraham_ isn't exactly sure which
947. # [23:27] <Philip`> hsivonen: wxWidgets used to implement everything (like strings) itself, largely copying the STL API, but now they've given up on old obscure platforms and have a (currently optional) option to use the STL implementations instead; so they're not confident enough to enable it by default, but they seem to be heading in that direction
948. # [23:27] <Philip`> gsnedders: All C++ applications reinvent many wheels :-)
949. # [23:27] <gsnedders> squares ftw!
950. # [23:28] * Quits: qwert666_ (n=qwert666@acag9.neoplus.adsl.tpnet.pl) ("Leaving")
951. # [23:29] <Philip`> It's often easier to rewrite code yourself rather than work out how to build and link to an external library, particularly if you want to work on multiple platforms
952. # [23:30] * aroben is now known as aroben|meeting
953. # [23:30] <Philip`> (at least if it's only a few hundred lines of code)
954. # [23:30] * gsnedders goes sleep
955. # [23:31] <gsnedders> The real W3C spec-gen is written in Perl and C, and parses the document about 10 times. It's ridiculous. It's possible to outdo that using even html5lib :P
956. # [23:32] * jgraham_ wonders if gsnedders should see a doctor about his sleep typing
957. # [23:32] <gsnedders> jgraham_: Hey, I have CFS, what do you expect? :P
958. # [23:32] <gsnedders> I'm ALWAYS asleep :P
959. # [23:32] <jgraham_> CFS?
960. # [23:33] * jgraham_ googles
961. # [23:33] * gsnedders points at http://wwcoco.com/cfids/mollyact1.html
962. # [23:33] <gsnedders> just 'cause it's by Molly
963. # [23:33] <gsnedders> (yes, that molly)
964. # [23:33] <Philip`> Isn't that a filesystem?
965. # [23:33] <gsnedders> Philip`: with an abbr. like that, I expect so :P
966. # [23:33] <Philip`> Any acronym that ends with FS is a filesystem
967. # [23:33] <jgraham_> Philip`: Oddly, that's what I thought of
968. # [23:34] <Philip`> gsnedders: There's nothing wrong with Perl!
969. # [23:34] <gsnedders> My brain runs on Confused File System.
970. # [23:34] <gsnedders> Philip`: I dislike it, but that's not the issue with the spec-gen, and is irrelevant :)
971. # [23:34] <Philip`> gsnedders: Your opinion on Perl is wrong
972. # [23:34] <gsnedders> hah.
973. # [23:35] <Philip`> You do like it, you just haven't realised yet
974. # [23:35] <gsnedders> Philip`: you remind me of my real friends.
975. # [23:35] <gsnedders> "You don't have an opinion. I'm right."
976. # [23:35] <jgraham_> Are they all crazy perl fans too?
977. # [23:35] <gsnedders> Seeming some of them struggle to use a computer at all, I doubt it
978. # [23:35] * Quits: mcarter (n=mcarter@ip-12-22-56-126.hqglobal.net) (Remote closed the connection)
979. # [23:36] * gsnedders notes while those two are around that he's only going to Cambridge once now this year, most likely, in May
980. # [23:38] * Philip` wonders when May is
981. # [23:38] <Philip`> Is that next month?
982. # [23:38] <gsnedders> Yes.
983. # [23:39] <Philip`> Ah, good
984. # [23:39] <gsnedders> Either of you have any suggestions for where to meet up, yet?
985. # [23:39] * jgraham_ wonders if he should parse that as "I will be going to Cambridge at at least once this year including one visit in May" or "I shall be going to Cambridge exactly once this year and it shall probably be in May"
986. # [23:39] <gsnedders> jgraham_: the commas should make it clear that it is the former
987. # [23:39] <Philip`> gsnedders: I don't know anything as practical as that, so I have no suggestions
988. # [23:40] <gsnedders> Philip`: :P
989. # [23:40] <jgraham_> gsnedders: I don't think the commas help
990. # [23:40] <gsnedders> Philip`: Am I going to end up choosing?
991. # [23:40] <jgraham_> gsnedders: I can come up with ideas if you want.
992. # [23:40] <Philip`> gsnedders: You could probably choose better than I can :-)
993. # [23:40] <gsnedders> As I said, somewhere centralish suits me.
994. # [23:41] <gsnedders> If not in the centre, in the direction of the Millpond
995. # [23:41] <jgraham_> The plan was to involve food, yes?
996. # [23:41] <gsnedders> Yeah, meet up over supper is probably best for me
997. # [23:41] <jgraham_> OK. Well we can sort something out based on cuisine preferences nearer the time
998. # [23:42] <Philip`> Preferably it would be somewhere within sane walking distance of me, since I'm not very good at travelling long distances
999. # [23:42] <gsnedders> Philip`: for any particular reason?
1000. # [23:42] <annevk> Lachy, "A new version of WordPress is available! Please notify the site administrator." << blog.whatwg.org
1001. # [23:42] <jgraham_> Philip`: You're at Kings, right? Or do you mean the CS department?
1002. # [23:42] <gsnedders> Philip`: Kings is hardly central, I know :)
1003. # [23:43] <gsnedders> Where is CS anyway?
1004. # [23:43] <jgraham_> Madingley Road, opposite Astronomy
1005. # [23:43] <jgraham_> :)
1006. # [23:43] <gsnedders> ah
1007. # [23:43] <Philip`> jgraham_: I'm living about 10-15 minutes south of King's
1008. # [23:43] <gsnedders> the latter part of that makes no sense to me, but the former part does
1009. # [23:44] <gsnedders> which way is the millpond from King's?
1010. # [23:44] <jgraham_> South west
1011. # [23:44] <gsnedders> I don't know where North/South is relative to Cambridge :)
1012. # [23:44] * Joins: epeus (n=KevinMar@106.sub-75-192-162.myvzw.com)
1013. # [23:44] * Philip` has no idea what the Millpond is
1014. # [23:44] <jgraham_> Not very west, mind
1015. # [23:45] <gsnedders> Philip`: by the Fen :)
1016. # [23:45] <gsnedders> </useless_answer>
1017. # [23:45] <gsnedders> Philip`: Where Bella Italia, and the Granta are
1018. # [23:45] <jgraham_> gsnedders: Equally good answers might have been "in the flat bit"
1019. # [23:45] * Quits: KevinMarks (n=KevinMar@209.139.210.235) (Nick collision from services.)
1020. # [23:45] <gsnedders> jgraham_: true :)
1021. # [23:45] <Philip`> Ah, I think I know that bit
1022. # [23:45] * epeus is now known as KevinMarks
1023. # [23:45] <Philip`> since I walk past it every day
1024. # [23:45] <gsnedders> Philip`: Yeah, exactly :)
1025. # [23:46] <Philip`> Depending on the time, I might start at the CL or at King's or at home, but they're all close enough to not make too much difference
1026. # [23:47] <gsnedders> What is there around there? Chinese, Indian, Italian, and several pubs? Or do I recall incorrectly?
1027. # [23:47] <jgraham_> I'll almost certainly be coming from the IoA
1028. # [23:47] <gsnedders> IoA?
1029. # [23:47] <jgraham_> Institute of Astronomy
1030. # [23:47] <gsnedders> I guessed that just after I asked
1031. # [23:47] <gsnedders> and that's opp. CS :)
1032. # [23:47] <Philip`> Depends which side you look at the opposite of
1033. # [23:48] <Philip`> The most directly opposite thing is a field with some horses
1034. # [23:48] * gsnedders checks Madingley Road is what he thought it was
1035. # [23:48] <jgraham_> gsnedders: Yeah, there's that bit. Then nearby there's a little bit with an (inexplicably) popular noodle bar and a couple of other places
1036. # [23:48] <gsnedders> I mean, we can always meet by the millpond and then decide where to go if need be
1037. # [23:49] <jgraham_> Or there's other places in town e.g. japanese
1038. # [23:49] <gsnedders> I'll be offline while I'm in Cambridge likely, as I probably won't take my laptop
1039. # [23:50] <Philip`> ( http://maps.google.com/maps?f=q&hl=en&geocode=&q=computer+laboratory&jsv=107&sll=52.21071,0.091882&sspn=0.006719,0.020771&ie=UTF8&ll=52.211104,0.091882&spn=0.006719,0.020771&t=k&z=16&iwloc=A )
1040. # [23:51] * Quits: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com) ("Ex-Chat")
1041. # [23:51] <gsnedders> yeah, perpendicular to the end of Grange Road (where my late grandmother lived) as I thought
1042. # [23:52] * Joins: mcarter (n=mcarter@ip-12-22-56-126.hqglobal.net)
1043. # [23:52] * Philip` sees the map is out of date, since the bit just south of the CL is now a building that looks quite like a very fat truncated submarine instead of a car park
1044. # [23:53] <gsnedders> Philip`: if you go by the millpond, I guess you live near Granchester Street?
1045. # [23:54] * Joins: starjive (i=beos@213-66-217-32-no30.tbcn.telia.com)
1046. # [23:54] <gsnedders> and on that, I really am going to sleep
1047. # [23:55] <Philip`> gsnedders: Yes - down that way and round a bit
1048. # [23:55] <gsnedders> Philip`: nice part :)
1049. # [23:55] * gsnedders really really goes
1050. # [23:55] <Philip`> It's quite a quiet area, which is nice :-)
1051. # [23:56] * Quits: phsiao (n=shawn@nat/ibm/x-b47b9ee27f6235d4)
1052. # [23:59] <hsivonen> does RTL alt test inherit dir from markup or put control characters in the attribute value?
1053. # [23:59] <hsivonen> s/test/text/
1054. # Session Close: Wed Apr 16 00:00:00 2008

The end :)