/irc-logs / freenode / #whatwg / 2008-01-18 / end

Options:

  1. # Session Start: Fri Jan 18 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:02] * Joins: othermaciej (n=mjs@17.203.15.209)
  4. # [00:05] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  5. # [00:16] * Quits: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com) ("Leaving")
  6. # [00:23] <zcorpan> Hixie: i used document.write('<pre>Failed ' + (tests.length - score) + ' of ' + tests.length + ' tests.\n' + log.replace(/&/g,'&amp;').replace(/</g,'&lt;').replace('\0', '\\0') + '</pre>');
  7. # [00:24] <Hixie> and that worked?
  8. # [00:24] <Philip`> zcorpan: Should be /\0/g, not '\0'
  9. # [00:26] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  10. # [00:28] <Hixie> well i've put that in
  11. # [00:28] <Hixie> no time to test it right now
  12. # [00:28] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  13. # [00:28] <Hixie> but let me know if it breaks anything if you try it before me
  14. # [00:29] * Quits: billmason (n=billmaso@ip129.unival.com) (Read error: 104 (Connection reset by peer))
  15. # [00:30] <zcorpan> it worked for me, yeah
  16. # [00:30] <zcorpan> Philip`: that didn't work
  17. # [00:30] <zcorpan> there's only one \0 in the string anyway
  18. # [00:32] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  19. # [00:37] <Philip`> zcorpan: Hmm, how did it not work?
  20. # [00:38] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3E%0D%0Avar%20s%3D'a%5C0b%5C0c'%3B%0D%0Aw(s.replace(%2F%5C0%2Fg%2C%20'%5C%5C0'))%3B%0D%0A%3C%2Fscript%3E seems to be doing the right replacements...
  21. # [00:40] <othermaciej> I think I know an easy way to fix tests 26 and 27 in WebKit
  22. # [00:40] <othermaciej> still not sure if it is a good idea though
  23. # [00:43] <SadEagle> othermaciej: interesting (but may be not for the rest of the channel :-) )
  24. # [00:44] <othermaciej> SadEagle: well, a few hours ago I was debating the test with people
  25. # [00:49] <SadEagle> othermaciej: well, I am curious about the potential solution, but this isn't the place for it
  26. # [00:52] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  27. # [00:57] * Quits: phsiao (n=shawn@nat/ibm/x-9f37440f3a1ab8ea)
  28. # [01:07] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  29. # [01:09] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  30. # [01:10] <zcorpan> hsivonen: shouldn't the html5 datatype library include link types?
  31. # [01:15] * Joins: aroben (n=aroben@unaffiliated/aroben)
  32. # [01:15] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  33. # [01:18] * Parts: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  34. # [01:23] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  35. # [01:41] * SadEagle is now known as AwayEagle
  36. # [01:42] * Quits: tndH (i=Rob@adsl-87-102-83-222.karoo.KCOM.COM) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  37. # [01:48] <Hixie> ah crap
  38. # [01:48] <Hixie> the next e-mail is about colour spaces
  39. # [01:48] * Hixie tries to see if the e-mail has any suggestion that would allow him to duck the entire issue neatly
  40. # [01:52] <Hixie> Philip`, o' Philip`, where art thou
  41. # [01:57] * Quits: roc (n=roc@202.0.36.64)
  42. # [01:57] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  43. # [01:59] * Joins: roc (n=roc@202.0.36.64)
  44. # [02:04] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  45. # [02:04] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  46. # [02:04] <Philip`> Hixie: *waves*
  47. # [02:05] * Joins: weinig_ (n=weinig@17.116.199.130)
  48. # [02:05] * Quits: aroben (n=aroben@unaffiliated/aroben) ("Leaving")
  49. # [02:05] <Hixie> Philip`: check out the new color section
  50. # [02:07] <Philip`> Hixie: Hmm, I don't really know much about colour spaces - I just assume everything is nice RGB 0-255 and then twiddle my monitor brightness until it looks alright
  51. # [02:07] <Hixie> i tried that
  52. # [02:07] <Hixie> but then you raised issues!
  53. # [02:07] <Hixie> :-P
  54. # [02:07] <Philip`> Oh, I don't remember that
  55. # [02:09] <Philip`> Since all my canvas tests assume there's no magical colour space conversion anyway, and browsers seem to pass the tests, I guess that means they do everything without conversions, which is good
  56. # [02:09] <Hixie> even for drawImage() of an image with gamma info?
  57. # [02:10] <Philip`> but I have no idea if they're really using sRGB or some device-specific colour space or something else
  58. # [02:10] <Hixie> and what does toDataURL return in its gamma information?
  59. # [02:10] * AwayEagle is now known as SadEagle
  60. # [02:10] <Hixie> what should putImageData() do if one of the pixels is 127.5 ?
  61. # [02:10] <Philip`> I haven't tried drawImage with gamma, since that sounds like it would lead to hard problems and I would get confused :-)
  62. # [02:10] <Hixie> ...has a component that is...
  63. # [02:11] <SadEagle> isn't there also possibility of rounding errors in e.g. JPEG decoders and such?
  64. # [02:12] <othermaciej> ugh, color spaces
  65. # [02:13] <othermaciej> it's probably sufficient to require that reading and writing pixels occurs in the same colorspace
  66. # [02:13] <othermaciej> (maybe you also require that it's the same colorspace used for any rendering done by CSS)
  67. # [02:14] <SadEagle> hmm, css3 color-profile inherits.
  68. # [02:14] <SadEagle> othermaciej: there is some nastiness there if you do a drawImage, though, since the 2 can have different css colorspaces set..
  69. # [02:14] <Philip`> Hixie: It would be helpful for authors if it was rounded, instead of throwing an exception
  70. # [02:14] <Philip`> but it doesn't matter which way it's rounded
  71. # [02:14] <Hixie> IEEE754r it is
  72. # [02:15] <Philip`> because e.g. Firefox does the canvas with premultiplied alpha, while Opera does it without, so you get imprecise results whatever you do
  73. # [02:15] <Philip`> (because a colour with alpha=0.5 has only 7 bits of precision for each colour component in Firefox)
  74. # [02:16] <Hixie> surely we need to fix that
  75. # [02:16] <Philip`> I don't see why
  76. # [02:16] <Hixie> doesn't that mean you'll get different results for the same code?
  77. # [02:16] <Hixie> or is it just a matter of accuracy
  78. # [02:17] <SadEagle> I doubt you'll get exact results with different rasterizers.
  79. # [02:18] <Philip`> About drawImage alpha: See http://software.hixie.ch/utilities/js/live-dom-viewer/ and 'download' if nobody's overwritten it - Firefox/Opera/Safari have the same output from the <canvas> as from the <img>s, though Safari (at least on Windows) does the gamma wrong (for some definition of 'wrong')
  80. # [02:18] <Philip`> Hixie: Not quite sure what you mean - if there's a matter with accuracy, then you will get different results for the same code because of the inaccuracy
  81. # [02:19] * Joins: harri (n=porten@mail.frogport.com)
  82. # [02:19] <harri> hi
  83. # [02:19] <othermaciej> are those images supposed to look the same, other than the number?
  84. # [02:19] <Philip`> othermaciej: http://www.libpng.org/pub/png/pngsuite.html says they should
  85. # [02:19] <gavin> Hixie: is the acid3 test in some kind of version control?
  86. # [02:19] <Hixie> Philip`: i mean, it's not like the alpha channel will have 1.0 in one browser and 0.5 in another, right? they'll both be roughly the same, just with different number of significant bits of accuracy?
  87. # [02:19] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  88. # [02:19] <othermaciej> ok (wasn't sure what the test was doing)
  89. # [02:20] <SadEagle> othermaciej: hmm, seems like I got something to fix.
  90. # [02:20] <othermaciej> Hixie: it's not the alpha channel that is mainly affected by premultiplied alpha, it's the color channels
  91. # [02:20] <Hixie> ok, so, the color channels will all be roughly the same? it's not like one will be 0 and the other 255?
  92. # [02:21] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  93. # [02:21] <Philip`> Hixie: If you draw rgba(255, 255, 255, 0) then do getImageData, Opera will return (255, 255, 255, 0) and Firefox will return (0, 0, 0, 0)
  94. # [02:21] <Hixie> getImageData says "Pixels must be returned as non-premultiplied alpha values."
  95. # [02:21] <Hixie> so that seems like a bug in firefox
  96. # [02:21] <othermaciej> on Mac, Firefox appears to draw those images lighter than Safari (probably due to not accounting for the system colorspace)
  97. # [02:21] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  98. # [02:22] <Philip`> Hixie: rgba(n, n, n, 0) converted to premultiplied alpha is (0, 0, 0, 0), so it's impossible to recover the colour components from it
  99. # [02:22] <gavin_> othermaciej: if you're using a trunk build, you could retry the test with gfx.color_management.enabled set to true
  100. # [02:22] <Hixie> Philip`: right
  101. # [02:22] <Hixie> Philip`: so, that's a bug.
  102. # [02:22] <Hixie> according to the spec
  103. # [02:22] <Philip`> If you draw something with zero alpha, nothing will ever get drawn, so it doesn't matter that the colour components were lost
  104. # [02:22] * Quits: Thezilch (n=fuz007@ip68-111-154-116.sd.sd.cox.net) (Read error: 104 (Connection reset by peer))
  105. # [02:23] <othermaciej> it only matters if you get the pixels back and do something to them that un-zeroes the alpha
  106. # [02:23] <Hixie> right
  107. # [02:23] <othermaciej> premultiplying is a good optimization
  108. # [02:23] <othermaciej> it would be unfortunate to rule it out
  109. # [02:23] <Philip`> Hixie: It's the same 'bug' as rgba(1, 2, 3, 0.5) being read back as something like (2, 2, 4, 127) - it's just a loss of precision, and when alpha=0 it's just ending up with zero precision
  110. # [02:24] <Philip`> so it's not like a horrible thing for the browser to do :-)
  111. # [02:25] <Hixie> well right now the spec rules it out
  112. # [02:25] <Philip`> I don't see where the spec rules it out
  113. # [02:26] <Hixie> 3.14.11.1.10. Pixel manipulation, first paragraph, last sentence
  114. # [02:26] <othermaciej> s/would be unfortunate/is unfortunate/
  115. # [02:26] * Joins: fredrikh (n=fredrik@kde/fredrik)
  116. # [02:26] <Hixie> i seem to recall responding to feedback that basically said that they really didn't want it premultiplied for some reason
  117. # [02:29] <Philip`> Hixie: That part isn't relevant - the canvas pixel colours are still being returned non-premultiplied, and nothing says that e.g. filling with (255,0,0,0) can't result in the canvas pixel colours being (0,0,0,0) and thus being returned as (0,0,0,0) from getImageData
  118. # [02:30] <othermaciej> is there a requirement that a putImageData / getImageData round trip has to return identical data?
  119. # [02:30] <Philip`> No
  120. # [02:30] <Philip`> (though there's a requirement that getImageData / putImageData has no effect)
  121. # [02:31] <Hixie> maybe i should make it clear that getImageData / putImageData / getImageData / putImageData should have no effect either
  122. # [02:31] <Philip`> I think that's clear already
  123. # [02:31] <othermaciej> that wouldn't affect premult
  124. # [02:31] <Philip`> because if get/put has no effect, then get/put/get/put can't possibly have any effect...
  125. # [02:32] <Hixie> though to be honest if 3.14.11.1.10. Pixel manipulation, first paragraph, last sentence doesn't apply here, i don't really understand what we're talking about
  126. # [02:32] <Hixie> which is unsurprising given my general ignorance in this region of the spec
  127. # [02:33] <othermaciej> (127, 127, 127, 0.5) would be stored internally as (64, 64, 64, 0.5) (I can't remember if you premultiply alpha by itself, but I think you don't) but would return (128, 128, 128, 0.5) when retrieving because premult is undone
  128. # [02:33] <Philip`> I think we're talking about the internal canvas representations not being required to have a specific precision
  129. # [02:34] <othermaciej> but (128, 128, 128, 0.5) and (127, 127, 127, 0.5) would draw the same thing
  130. # [02:34] <Hixie> oh i understand what Philip` meant earlier about the extreme 0 case meaning that data was "lost" but that really just being that the precision is lost
  131. # [02:35] <othermaciej> so a put/get cycle from arbitrary data might not retrieve the same data
  132. # [02:35] <Hixie> it's just that with alpha=0, the number of bits left is 0, so you'll always get 0 in the rgb components
  133. # [02:35] <othermaciej> but a get/put always would preserve contents
  134. # [02:35] <Hixie> ok
  135. # [02:35] <Philip`> (and so there's no point in worrying about whether 127.5 gets rounded to 127 or to 128, because it'll get clobbered by the conversion to the internal representation anyway)
  136. # [02:35] <Hixie> i don't care so much about that
  137. # [02:35] <othermaciej> Philip`: not if alpha is 1!
  138. # [02:36] <Philip`> othermaciej: Is there any point worrying about it in that specific case?
  139. # [02:36] <othermaciej> I don't think rounding mode of fractional pixels is that important, no
  140. # [02:36] <othermaciej> but not for the reason you stated
  141. # [02:37] <othermaciej> probably the simplest thing for implementations would be to do an ECMA-262 ToInt32 conversion on the provided pixel value
  142. # [02:37] <othermaciej> (I think that truncates)
  143. # [02:38] <Hixie> truncation is going to mean that you are always slightly off-white
  144. # [02:38] <Philip`> Since performance kind of matters here, is there some particular way of handling putImageData that would be as fast as possible while still being reasonably sane?
  145. # [02:39] <Philip`> (like, not doing lots of conversions and roundings and range checks for every component of every pixel because it'll make putImageData more unusably slow)
  146. # [02:40] <SadEagle> Philip`: it's much easier if you don't require the image data object to be an actual array
  147. # [02:40] <Philip`> SadEagle: What would be the alternative?
  148. # [02:40] <Hixie> my assumption has been that if you use getImageData then you get back something with a [[Class]] of ImageData that, when you set things to it, keeps the data in a really compact representation so long as you're only setting valid data
  149. # [02:40] <SadEagle> Philip`: An object with length and integer accessor properties.
  150. # [02:41] <Hixie> and expands to a normal JS object (which happens to have a [[Class]] of ImageData) if you do anything "wrong" (like set a pixel value to a string)
  151. # [02:42] <Philip`> Hixie: That sort of magic sounds annoying to implement
  152. # [02:43] <SadEagle> Philip`: anyway, if you do that, storing data in a native format, you only need to do conversion when JS explicitly requests it. And if JS is doing a lot of pixel throbbing, a few expensive ALU ops aren't gonna kill everything (even if their latency is gonna be hard to hide)
  153. # [02:43] <Hixie> well, if you don't, you have no choice but to type check and range check and so on
  154. # [02:43] <Philip`> e.g. when setting to a number, you'd have to work out whether that number was an integer and could be safely stored in the int[]
  155. # [02:43] <SadEagle> Philip`: no more than the imagedata in general.
  156. # [02:44] <SadEagle> It's not too disimilar from the native array object, but w/o the worry about autoboxing and whatnot.
  157. # [02:44] <SadEagle> one can just let JS properties shadow those of the internal impl.
  158. # [02:44] <SadEagle> s/autoboxing/small int/
  159. # [02:45] <Philip`> SadEagle: I think the usual uses of ImageData involve JS manipulating every pixel, so it needs to be optimised more for pixels that are accessed than for pixels that aren't
  160. # [02:46] <Philip`> Does nobody have a nice simple fast ByteArray in JS already? :-(
  161. # [02:47] <SadEagle> Philip`: again, array objects have all the tricks. The most obvious thing I can say: with a JS array, your cost per image color component is at least a pointer.
  162. # [02:47] <SadEagle> Philip`: with a specialized object, it's about a byte
  163. # [02:49] <Philip`> That wouldn't be a problem at all if we had 8-bit pointers
  164. # [02:49] <Philip`> I blame whoever thought we needed so much address space
  165. # [02:50] <SadEagle> then we wouldn't have to worry about JS iterating over megapixel images, too.
  166. # [02:50] * Philip` has forgotten what the original discussion was about now :-)
  167. # [02:51] <Hixie> ok, nobody tell Philip` about 64 bit architectures
  168. # [02:51] <SadEagle> premultiplied alpha and getPixelData/putPixelData
  169. # [02:51] <SadEagle> Philip`: are your tests up-to-date wrt to the spec changes?
  170. # [02:52] <Philip`> SadEagle: The path transformation tests aren't
  171. # [02:52] <Philip`> I don't think there have been any other spec changes that would have affected tests
  172. # [02:53] <fredrikh> Philip`: one of the shadow tests rely on a quirks mode in webkit for dashboard compatibility
  173. # [02:53] <Hixie> there, i made it so if you have a true ImageData object, then you can't store non-numeric data in there
  174. # [02:53] <Hixie> that should simplify matters a little
  175. # [02:53] <fredrikh> relies*
  176. # [02:54] <Philip`> fredrikh: Hmm, do you know which test or quirk that is?
  177. # [02:54] <fredrikh> Philip`: clip() clearing the path
  178. # [02:55] <fredrikh> in 2d.shadow.blur.low
  179. # [02:56] <SadEagle> Hixie: thanks. Does the website update quickly, or is there a more up-to-date way of looking at it
  180. # [02:56] <Hixie> SadEagle: it updates about 60 seconds after i say that i've updated it here
  181. # [02:56] <Hixie> sometimes longer
  182. # [02:56] <Hixie> (the regenning script takes a long time to run)
  183. # [02:56] <SadEagle> cool. Hmm, are images of about 4.2 billion pixels intended to be supported?
  184. # [02:56] <Philip`> fredrikh: Ah, thanks - it looks like 2d.path.clip.unaffected is meant to be testing that, so 2d.shadow.blur.low probably shouldn't
  185. # [02:57] <Hixie> SadEagle: UAs may have implementation-defined limits and may be subject to hardware limitations.
  186. # [02:57] * Philip` fixes in his local copy
  187. # [02:57] <SadEagle> Hixie: ah, the reason I asked was actually some subtle difference between how foo[1] and foo['1'] behaves.
  188. # [02:58] <SadEagle> where instead of 1, you use 2^32-1 :-)
  189. # [02:58] <Philip`> (Would be nice if everyone passed 2d.path.clip.unaffected in the same way, of course :-) )
  190. # [02:58] <Philip`> (but only Firefox follows the spec there, seemingly)
  191. # [02:58] <Hixie> SadEagle: yeah, not sure how to handle that exactly, i'm waiting on the dom bindings spec
  192. # [02:59] <Hixie> christ, the w3c site is getting slower every time i regen the spec
  193. # [02:59] <Hixie> sure looking forward to gsnedders' spec generator :-)
  194. # [03:00] <SadEagle> Philip`: hmm, I thought we passed that, but I gues snot
  195. # [03:01] <fredrikh> it's strange that we don't, because we do close the sub path
  196. # [03:03] <fredrikh> but while on the topic of shadows...
  197. # [03:03] * Joins: webben (n=benh@91.84.28.65)
  198. # [03:03] <fredrikh> Hixie: i'd really appreciate it if the spec didn't say that implementations must use the specified algorithm
  199. # [03:03] <Hixie> which one?
  200. # [03:03] <fredrikh> for shadows
  201. # [03:03] <Philip`> Why?
  202. # [03:04] <Philip`> (The specified algorithm ought to match what Safari does now)
  203. # [03:04] <fredrikh> in khtml we use a different filter that produces an effect that's very similar to a gaussian blur, but is many times faster
  204. # [03:04] <Hixie> fredrikh: Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent.
  205. # [03:05] <Philip`> Ah
  206. # [03:05] <fredrikh> Hixie: okay
  207. # [03:05] <takkaria> apparently someone needs to write Cookie5
  208. # [03:05] <Philip`> "equivalent" is fairly loose here since rounding/precision issues mean nobody's going to really notice if some values are off by a few percent
  209. # [03:05] <Hixie> right
  210. # [03:05] <SadEagle> Hixie: is it intended that drawImage function when the source image is the same canvas element as the destination?
  211. # [03:06] <Hixie> if there's some algorithm that looks like gaussian but happens to be an approximation, that's just an implemetation of gaussian blur that happens to approximate
  212. # [03:06] <Philip`> (or at least it means I'm willing to add lots of +/- value tolerance in my tests - I don't know if anybody else minds that :-) )
  213. # [03:06] <Hixie> SadEagle: what do browsers do now?
  214. # [03:09] * Philip` notes that his Firefox shadow patch is a (possibly poor) Gaussian approximation since it just chops off the ends of the distribution
  215. # [03:10] <SadEagle> Hixie: no idea, will try. Just a mental observation of a potential problem (after supper..)
  216. # [03:11] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ccanvas%20id%3Dc%3E%3C%2Fcanvas%3E%0D%0A%3Cscript%3E%0D%0Awindow.onload%20%3D%20function%20()%20%7B%0D%0Avar%20ctx%20%3D%20document.getElementById('c').getContext('2d')%3B%0D%0Actx.fillStyle%20%3D%20'red'%3B%0D%0Actx.fillRect(0%2C%200%2C%2050%2C%2050)%3B%0D%0Actx.drawImage(document.getElementById('c')%2C%2020%2C%2020)%3B%0D%0A%7D%0D%0A%3C%2Fscript%3E
  217. # [03:11] <Hixie> SadEagle: k
  218. # [03:12] <Hixie> Philip`: the real question is what happens if the source pixels would change value during the opueration
  219. # [03:12] <Hixie> e.g. using one of the PNG test images
  220. # [03:12] <Philip`> Firefox/Safari draw two red rectangles, Opera draws an endless chain of rectangles
  221. # [03:12] <Hixie> testing both bottom right and top left overlap
  222. # [03:13] <Philip`> so it is testing that already, and Opera loses :-)
  223. # [03:13] <Hixie> endless chain?
  224. # [03:13] <Philip`> s/Opera/Opera 9.2/
  225. # [03:13] <Hixie> oh right
  226. # [03:13] <Hixie> it paints the whole canvas
  227. # [03:13] <Philip`> (Opera 9.5 works like FF/S)
  228. # [03:13] <Hixie> i thought you were only painting the rect
  229. # [03:13] <Hixie> teehee
  230. # [03:13] <Hixie> cool
  231. # [03:14] * Philip` adds to his list of things to add tests for
  232. # [03:14] <fredrikh> Philip`: that's the only way to do it if you want reasonable performance, and the gaussian curve is effectively 0 after about 3 standard deviations
  233. # [03:16] <Hixie> is there a better way to say it than:
  234. # [03:16] <Hixie> <p>When a canvas is drawn onto itself, user agents must act as if
  235. # [03:16] <Hixie> the source was copied before the drawing operation started.</p>
  236. # [03:17] <Philip`> fredrikh: Apparently about 0.27% percent is outside +/- 3 sigma, so I guess that's fine since it'll be lost in the rounding errors
  237. # [03:17] <Philip`> Hixie: That's not necessary to state, since the drawing model already covers it
  238. # [03:17] <Hixie> really?
  239. # [03:18] <Philip`> The canvas would get drawn to the source image bitmap, and then it would get composited onto the canvas bitmap later
  240. # [03:18] <Hixie> valid, valid
  241. # [03:18] <Philip`> so it has to be read before anything is written
  242. # [03:18] * Hixie removes the paragraph
  243. # [03:19] <Hixie> i'll just add this note instead:
  244. # [03:19] <Hixie> <p class="note">When a canvas is drawn onto itself, the drawing
  245. # [03:19] <Hixie> model requires the source to be copied before the image is drawn
  246. # [03:19] <Hixie> back onto the canvas, so it is possible to copy parts of a canvas
  247. # [03:19] <Hixie> onto overlapping parts of itself.</p>
  248. # [03:19] <Hixie> unless you think even that is unnecessary (but someone asked the question, so...)
  249. # [03:20] <SadEagle> Hixie: thanks
  250. # [03:20] <Philip`> Seems sensible to have that note
  251. # [03:20] <fredrikh> Hixie: you could perhaps say that it's an atomic operation
  252. # [03:22] <Hixie> i think the drawing model describes that part well enough, as Philip` pointed out
  253. # [03:22] <Hixie> we should have an example of fudging with putImageData()
  254. # [03:22] <Hixie> anyone want to come up with a decent, useful filter that isn't long?
  255. # [03:23] <Philip`> http://canvex.lazyilluminati.com/misc/filter.html ?
  256. # [03:24] <Hixie> do you mind contributing that to the spec?
  257. # [03:25] <Philip`> I wouldn't mind at all, although it could probably doing with being cleaned up a bit first :-)
  258. # [03:25] <Hixie> yeah don't worry, i'll clean it up :-)
  259. # [03:25] <Hixie> i'll also change the image you use :-P
  260. # [03:26] <Philip`> (It's just a boring edge detection filter - don't know if it's got an official name or anything)
  261. # [03:26] <Philip`> That's the only image on the web whose URL I can remember
  262. # [03:26] <kig> laplacian edge detection or somesuch
  263. # [03:27] <Philip`> Oh, but I had to copy it to my own server because of the annoying security restrictions :-(
  264. # [03:27] * Philip` wonders about Access-Control for canvas images
  265. # [03:28] <Hixie> (grr, who's idea was it to make the Image() constructor take _dimensions_ as its argument. all i care about is the uri!)
  266. # [03:28] <Hixie> Philip`: let's wait for access-control to be resolved first :-)
  267. # [03:29] <kig> and do fast image filtering ops instead :9
  268. # [03:29] <Philip`> kig: Ah, yes, looks like it is Laplacian
  269. # [03:30] <Philip`> It would be great if we could generate Java bytecode in JS to do the filtering operation, and then tell the browser to compile and JIT it and run it on every pixel
  270. # [03:31] * Quits: weinig_ (n=weinig@17.116.199.130) (Read error: 110 (Connection timed out))
  271. # [03:32] <Hixie> Philip`: what's with the fillrects in that demo? :-)
  272. # [03:32] <Philip`> Hixie: That was to measure how much faster putImageData was
  273. # [03:33] <Philip`> "fillRects: 2606ms; putImageData: 30ms"
  274. # [03:33] <Hixie> k
  275. # [03:33] * Hixie deletes code
  276. # [03:34] <takkaria> Philip`: great is one word for it. :)
  277. # [03:35] <Philip`> Hmm, the isNaN thing is a bit ugly, but the alternative ways of filling the outermost 1-pixel edge of the image with 0 are a bit ugly too :-(
  278. # [03:40] <Philip`> (It would be much nicer to write this kind of code in C)
  279. # [03:41] <Philip`> (Oh, that's a good idea - web browsers should allow <script type="text/c">)
  280. # [03:41] <kig> gnu lightning
  281. # [03:43] <Philip`> You could use a self-hosted instance of the lcc compiler to convert C into whatever the JIT backend needs
  282. # [03:45] <Hixie> Philip`: download on http://software.hixie.ch/utilities/js/live-dom-viewer/
  283. # [03:45] <Hixie> what am i doing wrong
  284. # [03:46] <kig> GLSL is a lot nicer than C for graphics though
  285. # [03:46] * Quits: othermaciej (n=mjs@17.203.15.209)
  286. # [03:48] <Philip`> Hixie: Are you using something like FF2 on Linux?
  287. # [03:49] <Hixie> it worked on your demo
  288. # [03:49] <Hixie> but yes
  289. # [03:49] <Philip`> https://bugzilla.mozilla.org/show_bug.cgi?id=406036
  290. # [03:49] <Hixie> awesome
  291. # [03:49] <Philip`> There's a bug with images with certain dimensions
  292. # [03:49] <Philip`> which I guess might be what's breaking this
  293. # [03:49] <Hixie> is it working for you?
  294. # [03:49] <Philip`> (Your example works for me in FF3 on Windows, but not FF2 on Linux)
  295. # [03:49] <Hixie> k
  296. # [03:49] <Philip`> It looks pretty ugly, though :-p
  297. # [03:50] <Hixie> the code or the output? :-)
  298. # [03:50] <Philip`> The output
  299. # [03:50] <Philip`> I haven't looked at the code much :-)
  300. # [03:50] <Hixie> hehe
  301. # [03:51] <Philip`> I think it'd be good to at least get rid of the "var w4 = w*4" because it's not a sufficiently useful optimisation
  302. # [03:54] <Hixie> ok gotta go. regenning the spec, i'll commit it tomorrow.
  303. # [03:56] <Philip`> Okay, sounds good
  304. # [03:57] <Philip`> In the new spec, s/clamed/clamped/
  305. # [04:01] <Philip`> "The toDataURL() method must not include color space information in the resource returned." - hmm, I guess I need to write a PNG decoder to be able to test that...
  306. # [04:02] <Philip`> (Well, at least enough to parse out all the chunk types)
  307. # [04:02] <Philip`> Or I could not bother, which would be much easier
  308. # [04:03] <SadEagle> fredrikh: 77%
  309. # [04:04] <Philip`> Aha, if undefined is like 0 then the isNaN checks can be removed from clamp256, and the loops made to go 1<=y<h-1, 1<=x<w-1
  310. # [04:04] <Philip`> which is much nicer
  311. # [04:05] <Philip`> except you'd have to say "outputData.length = w*h*4" to make sure it's got the right number of undefineds
  312. # [04:06] <SadEagle> Philip`: wrt to 2d.composite.operation.darker --- was 'darker' removed from the spec at some point?
  313. # [04:06] <Philip`> SadEagle: Yes
  314. # [04:07] <SadEagle> I see, thanks. *removes*
  315. # [04:08] <Philip`> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011386.html etc
  316. # [04:08] <Philip`> (Firefox/Opera/Safari all implemented it totally differently)
  317. # [04:09] <takkaria> Philip`: it's not hard to write a PNG decoder that just does that
  318. # [04:09] <Philip`> takkaria: In JavaScript? :-)
  319. # [04:09] <takkaria> you have a fair point there
  320. # [04:10] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  321. # [04:11] * Quits: roc (n=roc@202.0.36.64)
  322. # [04:13] * Philip` tries to work out what Gecko 1.8.1.12 is
  323. # [04:13] <Philip`> I think that's going to be Firefox 2.0.whatever
  324. # [04:14] <Philip`> so that should mean Firefox 2 will get a working putImageData
  325. # [04:14] <SadEagle> 1.8.1.11 is 2.0.0.11
  326. # [04:14] <SadEagle> that's almost binutils-like
  327. # [04:14] <SadEagle> Philip`: uh-oh. Now I definitely will have to implement that ;-)
  328. # [04:15] * Joins: roc (n=roc@202.0.36.64)
  329. # [04:15] <Philip`> (where "working" means "buggy" because it's still returning premultiplied colours, I think)
  330. # [04:15] <Philip`> (but at least you can work around that in JS)
  331. # [04:29] <Philip`> fredrikh: Oops, I just noticed I misinterpreted what you said about 2d.shadow.blur.low - I thought shadow bugs were being masked by clip bugs, but actually the test was relying on those clip bugs...
  332. # [04:29] <fredrikh> Philip`: right
  333. # [04:30] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
  334. # [05:32] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  335. # [05:39] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net) ("durr...")
  336. # [05:41] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  337. # [05:45] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  338. # [05:52] <kig> Philip`: re: canvas 2d impl in opengl, going to do it?
  339. # [06:17] * Quits: fredrikh (n=fredrik@kde/fredrik) ("bbl")
  340. # [06:18] * SadEagle is now known as AwayEagle
  341. # [06:24] * Quits: roc (n=roc@202.0.36.64)
  342. # [06:42] * Joins: jwalden (n=waldo@RANDOM-SEVENTY-TWO.MIT.EDU)
  343. # [06:53] <jwalden> Hixie: there's an instructions.in/test 5 asymmetry again :-)
  344. # [07:04] <annevk> Hixie, s/clamed to 255/clamped to 255/
  345. # [07:04] <jwalden> s/in\//inc\//
  346. # [07:09] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 110 (Connection timed out))
  347. # [07:17] <annevk> hmm, Acid3 is testing @font-face now?
  348. # [07:18] <annevk> is that the purple "X" ?
  349. # [07:18] <jwalden> wow
  350. # [07:18] <annevk> so it seems
  351. # [07:19] <jwalden> fun times
  352. # [07:19] * jwalden gasps
  353. # [07:19] <jwalden> it's not an EOT font!
  354. # [07:20] <annevk> that same test also tests positioned generated content, nice
  355. # [07:23] <othermaciej> omg Hixie is teh font pirate!!!111
  356. # [07:26] <MacDome> annevk: is that what the red square in the upper right corner is?
  357. # [07:26] <MacDome> hum.. hixie.ch is failing to load
  358. # [07:26] <annevk> MacDome, an "X" drawn in the Ahem font is supposed to cover that
  359. # [07:27] <MacDome> we support @font-face...
  360. # [07:27] * MacDome wonders what sort of @font-face madness he's doing
  361. # [07:27] <annevk> do you support positioned generated content though?
  362. # [07:27] <othermaciej> probably
  363. # [07:28] <annevk> otherwise the X will not be on top of the red square (the "X" is also invisible if you support @font-face afaict)
  364. # [07:32] <annevk> is there some documentation on what subset of descriptors WebKit supports?
  365. # [07:36] <MacDome> annevk: for @font-face? not many
  366. # [07:37] <annevk> i'm all for not many, just wondering which :)
  367. # [07:39] * Joins: MacDome_ (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  368. # [07:39] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  369. # [07:43] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  370. # [08:09] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  371. # [08:16] <othermaciej> UTSL
  372. # [08:16] <othermaciej> I do not think it is documented otherwise
  373. # [08:18] <annevk> it's not that strong with me it seems
  374. # [08:32] <hsivonen> zcorpan: link types are extensible and the extensibility mechanism is unstable
  375. # [08:39] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  376. # [08:52] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  377. # [09:07] * Quits: AwayEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) (Remote closed the connection)
  378. # [09:07] * Joins: roc (n=roc@121-72-37-29.dsl.telstraclear.net)
  379. # [09:07] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  380. # [09:08] * MacDome_ is now known as MacDome
  381. # [09:17] * MacDome is now known as MacDomeSleep
  382. # [09:32] * Joins: tndH_ (i=Rob@adsl-87-102-83-222.karoo.KCOM.COM)
  383. # [09:32] * tndH_ is now known as tndH
  384. # [09:56] * Quits: webben (n=benh@91.84.28.65)
  385. # [09:59] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  386. # [10:07] * hsivonen notes that Opera violates the HTML5 requirement that UAs MUST NOT support UTF-7
  387. # [10:13] * Joins: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl)
  388. # [10:15] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  389. # [10:15] * Joins: a_magical_me2 (n=a_magica@c-67-171-194-99.hsd1.or.comcast.net)
  390. # [10:16] * Parts: a_magical_me2 (n=a_magica@c-67-171-194-99.hsd1.or.comcast.net)
  391. # [10:17] <Lachy> what's the reason for forbidding UTF-7?
  392. # [10:17] <Lachy> other than it being a totally useless encoding for the web
  393. # [10:19] * Quits: jgraham (n=james@81-86-212-85.dsl.pipex.com) ("This computer has gone to sleep")
  394. # [10:21] * Joins: ROBOd (n=robod@89.122.216.38)
  395. # [10:23] <hsivonen> Lachy: it is a security problem, too
  396. # [10:26] <Philip`> kig: I'm not planning to do that
  397. # [10:32] * Joins: webben (n=benh@nat/yahoo/x-1108a511de960215)
  398. # [10:33] <annevk> hsivonen, what's the scenario?
  399. # [10:36] <hsivonen> annevk: an attacker injects UTF-7 encoded evil code into a forum. the forum software assumes that Basic Latin and ASCII bytes have a sane correspondence and doesn't filter out the evil attack code.
  400. # [10:37] <hsivonen> annevk: the user is somehow tricked to selecting UTF-7 (e.g. by simply posting an instruction to do so; so gullible people will fall for it).
  401. # [10:37] <hsivonen> annevk: the attack code runs
  402. # [10:39] <Lachy> Firefox supports UTF-7 too
  403. # [10:39] <Lachy> and IE
  404. # [10:40] * Joins: Camaban (n=adrianle@81.133.236.158)
  405. # [10:40] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  406. # [10:40] <othermaciej> Safari doesn't let you pick UTF-7 from the encoding menu in the UI at least
  407. # [10:40] <othermaciej> though I dunno if it supports it generally
  408. # [10:41] <othermaciej> 8-bit encodings where ASCII is not ASCII are bad mojo
  409. # [10:41] * Parts: Camaban (n=adrianle@81.133.236.158)
  410. # [10:41] <hsivonen> Lachy: I think there's a bug about disabling UTF-7 from Gecko wherever feasible
  411. # [10:42] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  412. # [10:42] <Lachy> it's most insecure when auto-detect is enabled and allowed to switch to UTF-7 automatically
  413. # [10:43] * Joins: Camaban (n=adrianle@81.133.236.158)
  414. # [10:44] <hsivonen> https://bugzilla.mozilla.org/show_bug.cgi?id=408457
  415. # [10:44] <hsivonen> https://bugzilla.mozilla.org/show_bug.cgi?id=406777
  416. # [10:46] * hsivonen has very little sympathy for authors whose sites would break due to UTF-7 getting disabled
  417. # [10:46] <Lachy> I wonder how many sites are actually using UTF-7
  418. # [10:47] <hsivonen> probably in the same ballpark with UTF-32 usage
  419. # [10:48] <hsivonen> is there an easy way to test whether an encoding is ebcdic-based?
  420. # [10:48] <annevk> UTF-32 is not used
  421. # [10:48] <hsivonen> annevk: it is by test suites, I believe
  422. # [10:48] <Lachy> test suites don't matter
  423. # [10:48] <annevk> yeah, test suites caused us to support it iirc
  424. # [10:49] <hsivonen> coming up with new character encodings should carry an even more drastic punishment than coming up with new C++ features
  425. # [10:49] <Lachy> if it's only test suites using it, then that's not real world usage and it can be dropped
  426. # [10:49] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) (Read error: 110 (Connection timed out))
  427. # [10:52] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  428. # [10:57] <hsivonen> is x-JISAutoDetect a real Web encoding decl or an ICU internal magic name?
  429. # [11:03] <hsivonen> are there encodings that aren't either: 1) ASCII-based, 2) EBCDIC-based or 3) designed for Unicode?
  430. # [11:06] <roc> definitely
  431. # [11:07] <MikeSmith> isn't JISAutoDetect a Java-specific thing?
  432. # [11:07] <roc> lots of the older Asian encodings for example
  433. # [11:07] <hsivonen> MikeSmith: perhaps. I'll put in on the banned list.
  434. # [11:07] <MikeSmith> hsivonen - I'll also ask Felix Sasaki about it
  435. # [11:07] <MikeSmith> I reckon he'll know for sure
  436. # [11:08] <hsivonen> (the banned list is stuff that the Validator.nu deployment has decoders for but that a Web-facing piece of software should not support)
  437. # [11:09] <roc> Big5 and GB2312 for example
  438. # [11:09] <hsivonen> roc: ah. ok.
  439. # [11:09] * hsivonen thought GB stuff was ASCII-based
  440. # [11:10] <hsivonen> roc: according to my test code, ASCII bytes decode to corresponding Basic Lating in Big5 and GB2312
  441. # [11:11] <roc> well, if that's what you mean by ASCII based...
  442. # [11:11] <roc> then Unicode is ASCII based too :-)
  443. # [11:11] <roc> The mappings for bytes 00-7F are actually not specified by Big5 or GB2312 or comparable encodings
  444. # [11:11] <hsivonen> roc: well, UTF-8 and CESU-8
  445. # [11:12] <roc> they're just "whatever the system does"
  446. # [11:12] <hsivonen> oh. that's bad
  447. # [11:12] <roc> http://en.wikipedia.org/wiki/Big5
  448. # [11:12] <hsivonen> ASCII is de facto, though, isn't it?
  449. # [11:12] <roc> "The modern characterization of Big5 as an MBCS consisting of the DBCS of Big5 plus the SBCS of ASCII is therefore historically incorrect and potentially flawed, as the choice of the matching SBCS was, and theoretically still is, quite independent of the flavour of Big5 being used."
  450. # [11:13] <hsivonen> I care about the IANA meaning and actual Web usage
  451. # [11:15] <hsivonen> more specifically, I'm right now implementing checking for the HTML5 requirements about encodings implementations MUST NOT support, authors SHOULD NOT use and the ASCII superset requirement
  452. # [11:16] <hsivonen> Hixie: you have a definition for ASCII supersetness but you don't say how to tell if an encoding is EBCDIC-based
  453. # [11:18] <hsivonen> It seems that the stuff on my non-ASCII list consists of UTF-16, UTF-32, ISCII, legacy dingbat stuff, a couple of Japanese and Korean encodings and an insane number of IBM encodings
  454. # [11:18] <hsivonen> it looks almost safe to whitelist UTF-16 and complain about all other non-ASCII-superset encodings
  455. # [11:21] <hsivonen> hmm. or perhaps this heuristic works for non-x-encodings: if non-ASCII-superset and name starts with "cp" or "ibm", the encoding falls under the EBCDIC SHOULD NOT
  456. # [11:33] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  457. # [11:35] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  458. # [11:35] <zcorpan> hsivonen: while you're at it, you could warn about encodings other than utf-8 and utf-16 for xml
  459. # [11:36] <zcorpan> (or drop support for other encodings altogether, although that probably makes the validator less useful)
  460. # [11:37] <hsivonen> zcorpan: Don't I already warn about them? (other than ISO-8859-1 and US-ASCII that is)
  461. # [11:37] * annevk hopes hsivonen does not warn about text/xml
  462. # [11:38] <annevk> s/hsivonen/validator.nu/ :p
  463. # [11:39] <hsivonen> annevk: I don't remember what exactly the text/xml warning are, but I think I warn if charset= is missing on the HTTP level
  464. # [11:39] <annevk> :(
  465. # [11:40] <hsivonen> annevk: isn't your patch about that still in queue for Gecko? might be a good idea to suggest that it not be checked in
  466. # [11:41] <zcorpan> hsivonen: oh, i just tested with iso-8859-1
  467. # [11:41] <annevk> so far I only updated some architecture
  468. # [11:41] <hsivonen> zcorpan: warning about iso-8859-1 and us-ascii seems unproductive considering implementation reality
  469. # [11:42] <zcorpan> hsivonen: true
  470. # [11:42] <annevk> isn't iso-8859-1 really windows-1252?
  471. # [11:42] <hsivonen> annevk: not in Validator.nu XML support
  472. # [11:43] * annevk wonders what the various control characters do in browsers
  473. # [11:43] <hsivonen> C1 range should give a warning in V.nu
  474. # [11:45] <hsivonen> annevk: the lax type checkbox turns off RFC 3023 uselessness.
  475. # [11:46] <hsivonen> but if the checkbox is unchecked, I'm eligible for the t-shirt
  476. # [11:58] * Quits: roc (n=roc@121-72-37-29.dsl.telstraclear.net)
  477. # [12:00] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  478. # [12:03] <MikeSmith> fyi, I've set up the following page to document milestones related to HTML over the last 10 years (between publication of the HTML 4.0 Rec and creation of the current HTML WG) and to try to provide context for HTML5
  479. # [12:03] <MikeSmith> http://esw.w3.org/topic/HTML/history
  480. # [12:04] <MikeSmith> I'm sure there are some things of significance that I've missed, so if anybody notices such, please add it.
  481. # [12:05] <MikeSmith> Or change anything that's not accurate
  482. # [12:05] <MikeSmith> If you do add or change anything, please also include a comment indicating what you added or changed.
  483. # [12:15] <Philip`> "first compatible native implementation of XMLHttpRequest" - compatible with what?
  484. # [12:17] <annevk> the APIs matched
  485. # [12:17] <annevk> though getting the object was slightly different
  486. # [12:17] <annevk> i should say "matched"
  487. # [12:17] * Joins: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl)
  488. # [12:23] <MikeSmith> Philip` - I copied that wording directly from Wikipedia. I don't know what it means either. I guess it means compatible with the implementation in IE6.
  489. # [12:38] <MikeSmith> ..
  490. # [12:39] <MikeSmith> What kinds of Web applications are the use cases behind the Network Connections part of the current HTML5 spec?
  491. # [12:39] <MikeSmith> http://www.w3.org/html/wg/html5/#network
  492. # [12:40] <Dashiva> Chat rooms and such, maybe?
  493. # [12:40] <annevk> p2p games, avoiding overhead of HTTP
  494. # [12:41] <MikeSmith> OK
  495. # [12:43] <MikeSmith> recent discussions around Access Control leave me thinking it might be a worthwhile to try to start getting use cases documented for various parts of the HTML5 spec
  496. # [12:43] <annevk> probably, yeah
  497. # [12:43] <annevk> sigh
  498. # [12:45] <MikeSmith> yeah, definitely worthy of a big sigh
  499. # [12:45] <MikeSmith> maybe can get some people to volunteer to do the work of gathering the use cases and documenting them and maintaining the doc
  500. # [12:46] <MikeSmith> would be quite different work than spec-editing, with nowhere near the same need of technical expertise to write it up
  501. # [12:48] <annevk> yup
  502. # [12:49] <annevk> i think i've address all the concerns with access control now
  503. # [12:49] <annevk> addressed*
  504. # [13:05] * Quits: webben (n=benh@nat/yahoo/x-1108a511de960215)
  505. # [13:20] <takkaria> http://users.ecs.soton.ac.uk/jmb/test/cookies.php
  506. # [13:31] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  507. # [13:35] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  508. # [13:39] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  509. # [13:43] <hsivonen> MikeSmith: hmm. the wiki should probably mention the introduction of doctype sniffing. I don't have the dates at hand. Tantek and Peter Linss probably recall the historical specifics.
  510. # [13:43] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  511. # [13:43] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  512. # [13:44] <MikeSmith> hsivonen - If you can have time to find dates for that, I'd appreciate it
  513. # [13:45] <MikeSmith> I'm reminded now that I wanted to add the date for first public launch of your conformance checker
  514. # [13:45] <MikeSmith> and also for validator.nu launch
  515. # [13:46] <hsivonen> I'll see if I can dig up some the dates
  516. # [13:49] <MikeSmith> thanks
  517. # [14:05] <Philip`> You could list all the occasions that the HTML WG has agreed on something
  518. # [14:10] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  519. # [14:18] * Joins: webben (n=benh@nat/yahoo/x-e69a43b7cd7b5844)
  520. # [14:21] <hsivonen> sigh. so much character encoding code tweaking
  521. # [14:21] <hsivonen> everyone should just use utf-8
  522. # [14:24] <Philip`> Everyone should just use us-ascii and NCRs
  523. # [14:24] <takkaria> everyone should use utf-7, the imap version
  524. # [14:25] <hsivonen> takkaria: oh, yeah, the IMAP version... I found out about it earlier today and put it on the banned list
  525. # [14:25] <Philip`> All characters should be encoded as PNGs
  526. # [14:25] <jwalden> nope, not enough XML
  527. # [14:26] * takkaria has a printed copy of the IMAP spec for when he can't get to sleep
  528. # [14:26] <OmegaJunior> And the screen readers (audio) should recognise the pattern in the PNG character and interpret it as a sound.
  529. # [14:27] <Philip`> Sounds like IMAP UTF-7 doesn't have the security problems of plain UTF-7, since ASCII characters can't be encoded as multiple bytes
  530. # [14:27] <Philip`> OmegaJunior: PNG is extensible so we can add a new chunk that gives a textual representation of the image
  531. # [14:28] <OmegaJunior> And an audio representation?
  532. # [14:28] <Philip`> That would be a good way of making accessible CAPTCHAs, actually
  533. # [14:28] <OmegaJunior> Not if it has the text rep built in... automated retrieval not good for security
  534. # [14:28] <Philip`> OmegaJunior: I'm not sure why that would be needed - screen readers can convert the text to audio
  535. # [14:29] <OmegaJunior> Less CPU power needed by the screen readers :)
  536. # [14:29] <Philip`> They can make up for that CPU power usage by disabling the graphics output
  537. # [14:29] <OmegaJunior> true
  538. # [14:37] <zcorpan> getting innerHTML: "If one of the ancestors of the child node is a style, script, xmp, iframe, noembed, noframes, noscript, or plaintext element, then append the value of the child node's data DOM attribute literally."
  539. # [14:38] <zcorpan> perhaps that should say "If the parent node of the child node ..." in order to make the algorithm more performant while still DTRT in normal cases
  540. # [14:40] * Quits: jwalden (n=waldo@RANDOM-SEVENTY-TWO.MIT.EDU) (Remote closed the connection)
  541. # [14:42] <zcorpan> in fact, firefox seems to only serialize the child text nodes of e.g. <script>
  542. # [14:45] * Joins: vant (n=vant@p4104-ipbf906marunouchi.tokyo.ocn.ne.jp)
  543. # [14:46] <zcorpan> but opera serializes all children and only checks parent for deciding about < vs. &lt;
  544. # [14:46] * zcorpan sends email
  545. # [14:51] <zcorpan> actually, i guess the spec could be implemented in a performant way by just using a flag
  546. # [14:52] <annevk> it's not quite clear if what the spec says is nice for <script><?test alert(1)?></script>
  547. # [14:52] <annevk> which is not entirely unlikely if you copy and paste nodes of responseXML into your own DOM and then serialize
  548. # [14:53] <zcorpan> i've complained about serializing PIs
  549. # [14:53] <annevk> same applies to comments i guess
  550. # [14:54] <zcorpan> what do you mean? you think comments should be omitted from the serialization?
  551. # [14:55] <zcorpan> (firefox omits them)
  552. # [14:55] <annevk> i'm not sure if what is being said for <script> etc. makes sense for comments
  553. # [14:56] * Joins: aroben (n=aroben@68.63.168.13)
  554. # [14:57] <zcorpan> the spec says to serialize them as normal. which we do, but firefox doesn't
  555. # [14:59] <zcorpan> neither roundtrips correctly of course, but omitting probably roundtrips better than not omitting
  556. # [15:01] <Philip`> Hixie: I'd suggest changing the edge filtering demo to be more like http://philip.html5.org/demos/canvas/edgedetect.html - the clamping is now unnecessary, and the edges can be handled by setting .length so they are undefined and thus black
  557. # [15:02] <Philip`> (This doesn't work in Firefox or in Opera 9.5, though)
  558. # [15:26] * Joins: webben_ (n=benh@nat/yahoo/x-957f7939b1dbcdc2)
  559. # [15:33] * Quits: webben (n=benh@nat/yahoo/x-e69a43b7cd7b5844) (Read error: 110 (Connection timed out))
  560. # [15:50] * Joins: csarven (n=nevrasc@on-irc.csarven.ca)
  561. # [16:07] * Joins: webben (n=benh@nat/yahoo/x-62feae4f8e5fccb6)
  562. # [16:16] * Quits: webben_ (n=benh@nat/yahoo/x-957f7939b1dbcdc2) (Read error: 113 (No route to host))
  563. # [16:18] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  564. # [16:18] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  565. # [16:22] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  566. # [16:22] * Joins: billmason (n=billmaso@ip129.unival.com)
  567. # [16:28] <zcorpan> Hixie: in test 1, you have
  568. # [16:28] <zcorpan> case 1: case 3: case 4: case 6: case 7: case 8: case 9: case 12: case 12: throw exception;
  569. # [16:28] <zcorpan> was it intended to list "case 12" twice?
  570. # [16:30] * Joins: phsiao (n=shawn@nat/ibm/x-c7bc1de0ed400dd9)
  571. # [17:02] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) ("Trillian (http://www.ceruleanstudios.com")
  572. # [17:08] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  573. # [17:11] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  574. # [17:12] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Client Quit)
  575. # [17:12] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  576. # [17:22] <gsnedders> takkaria: Cookie5 falls into the HTTPbis work, IIRC
  577. # [17:23] <gsnedders> (and parsing and dealing of invalid things falls into my own draft, as the WG seems to not want to do it itself)
  578. # [17:28] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  579. # [17:28] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  580. # [17:32] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  581. # [17:32] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  582. # [17:42] <Philip`> http://www.cisco.com/univercd/illus/6/42/65242.jpg - hmm, I think this is the first time I've noticed a web site with small print that can't be made readable by increasing the font size
  583. # [17:47] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  584. # [17:47] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  585. # [17:48] * Quits: csarven (n=nevrasc@on-irc.csarven.ca) (Read error: 104 (Connection reset by peer))
  586. # [17:50] * Joins: maikmerten (n=maikmert@T78f0.t.pppool.de)
  587. # [17:51] * Quits: vant (n=vant@p4104-ipbf906marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  588. # [18:07] * Lachy_ is now known as Lachy
  589. # [18:07] * Joins: BlueG (n=blue@24-151-197-147.dhcp.kgpt.tn.charter.com)
  590. # [18:07] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  591. # [18:07] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  592. # [18:08] * Joins: jwalden (n=waldo@RANDOM-SEVENTY-TWO.MIT.EDU)
  593. # [18:14] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  594. # [18:24] <gsnedders> is there any way to get back to a DOM from a tree walker?
  595. # [18:25] <gsnedders> (in html5lib)
  596. # [18:42] <BlueG> should I use xhtml or html for my web site, and why?
  597. # [18:43] * Joins: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net)
  598. # [18:44] <Philip`> BlueG: You should, because the alternatives are usually proprietary technologies from a single vendor and don't have as wide adoption as (X)HTML
  599. # [18:45] <SadEagle> does anyone perchance know of any good dom traversal testsuites?
  600. # [18:45] * Joins: webben_ (n=benh@nat/yahoo/x-bfd07eee5ef9bb79)
  601. # [18:47] * Quits: webben (n=benh@nat/yahoo/x-62feae4f8e5fccb6) (Read error: 113 (No route to host))
  602. # [18:49] <BlueG> Philip`: I meant I want to know why to choose one of the two over the other...
  603. # [18:51] * Quits: webben_ (n=benh@nat/yahoo/x-bfd07eee5ef9bb79)
  604. # [18:51] <Camaban> a bit OT for this channel, but considering virtually all 'XHTML' sites serve content as if they are HTML, there's virtually only one option
  605. # [18:51] <BlueG> would it be legitimate to serve xhtml code with content negotiation so that all of the browsers that support the application/xml+xhtml mime type get it that way, and IE recieves it at text/html?
  606. # [18:51] <Camaban> BlueG: it states you can do that in the XHTML spec
  607. # [18:51] <Philip`> BlueG: What would be the benefit of doing that?
  608. # [18:54] <BlueG> I am told that serving xhtml at text/html is a bad idea, loosing most of the benefits of using xhtml, but that IE doesn't understand the proper mime type
  609. # [18:54] <SadEagle> what are the benefits of using xhtml? :-)
  610. # [18:56] <BlueG> good question. I have read a few things, but what I am really wanting to know is whether I should use xhtml or html and why
  611. # [18:56] <Philip`> BlueG: If the application/xhtml+xml (in Firefox etc) and text/html (in IE etc) versions of the page have the same features, then you aren't using any of the features that XHTML provides, and you might as well send it as text/html to everyone because it's easier and less likely to break
  612. # [18:58] <Philip`> (Er, any of the *new* features that XHTML provides)
  613. # [18:58] <BlueG> would I be better off using html 4.01, instead of xhtml 1.0?
  614. # [18:58] <Camaban> BlueG: if you serve XHTML as text/html, you may as well use HTML anyway, as the browser looks at it in the same way. And you can't send XHTML as XTHML because IE doesn't like it.... So either use HTML, or use XHTML as if it's HTML, the end result is, it gets treated as HTML
  615. # [18:58] <Philip`> You can send XHTML as XHTML if you don't mind blocking IE users :-)
  616. # [18:59] <Camaban> well, that's an option that is rarely open :)
  617. # [18:59] <BlueG> hehe... maybe I don't... :-)
  618. # [18:59] <BlueG> it's my personal web page... I can do what I want :-p
  619. # [19:00] <BlueG> what are the advantages of xhtml when actually served as xhtml anyways?
  620. # [19:00] <Camaban> unless you have a particular penchant for XHTML (I tend to code in it still because I got use to it before I knew that there was no point) then HTML4.01 strict is your best bet
  621. # [19:00] <SadEagle> BlueG: your browser will tell you if you made a stupid typo in a closing tag.
  622. # [19:00] <Camaban> http://www.w3.org/MarkUp/2004/xhtml-faq#advantages
  623. # [19:01] * Joins: anne-mibbit (i=5352d922@gateway/web/ajax/mibbit.com/x-fb2e6b8e167828f2)
  624. # [19:01] * Parts: Camaban (n=adrianle@81.133.236.158)
  625. # [19:01] <SadEagle> does anyone actually use/support XForms?
  626. # [19:02] * Joins: ROBOd (n=robod@89.122.216.38)
  627. # [19:02] <Philip`> BlueG: Inline SVG seems to be the most common benefit from using XHTML
  628. # [19:03] <Philip`> I can't think of much else that is used in practice, except for some rare MathML
  629. # [19:03] <anne-mibbit> yeah, we need to port that to HTML in due course
  630. # [19:04] <Philip`> SadEagle: Is that an advantage? :-)
  631. # [19:07] <SadEagle> Philip`: the FAQ above lists it as one :-)
  632. # [19:07] <gsnedders> SadEagle: Gecko does with an extension to give a UI
  633. # [19:07] <gsnedders> (IIRC that's all the extension does, the dealing with the data is in gecko)
  634. # [19:07] <Philip`> SadEagle: (I was referring to the typo thing, rather than XForms)
  635. # [19:09] <SadEagle> Philip`: it does reduce the chance of unexpected parsing incompatibilities. But then, one should validate against the DTD if one really cares, anyway :-)
  636. # [19:10] * Joins: eseidel (n=eseidel@nat/google/x-324b51bd5cfcff6b)
  637. # [19:10] * Quits: eseidel (n=eseidel@nat/google/x-324b51bd5cfcff6b) (Client Quit)
  638. # [19:10] <anne-mibbit> don't say that in here
  639. # [19:10] <Philip`> Don't say DTD?
  640. # [19:11] <anne-mibbit> DTD and validate in one sentence :)
  641. # [19:11] <Philip`> Aren't the non-validation uses of DTDs even worse? :-)
  642. # [19:11] * Joins: eseidel (n=eseidel@nat/google/x-285b229306ceffdf)
  643. # [19:12] <anne-mibbit> well, DTD then
  644. # [19:13] <Philip`> Okay, I won't say DTD then
  645. # [19:13] * Joins: csarven (n=nevrasc@on-irc.csarven.ca)
  646. # [19:14] <anne-mibbit> :evil:
  647. # [19:14] <Philip`> krijnh: I think you need to erase the last 6 lines from the log because we don't say DTD in here
  648. # [19:14] * SadEagle apologizes in multiple languages
  649. # [19:15] <SadEagle> May I use "tree grammar", though?
  650. # [19:15] <gsnedders> anne-mibbit: mibbit?
  651. # [19:15] <Philip`> I think we don't like grammars
  652. # [19:16] <anne-mibbit> gsnedders, it's Web IRC interface (mibbit.com)
  653. # [19:16] <anne-mibbit> and it's pretty decent too
  654. # [19:22] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  655. # [19:23] * Joins: roc (n=roc@121-72-37-29.dsl.telstraclear.net)
  656. # [19:23] <BlueG> what is the deal with not saying "D" acronym?
  657. # [19:23] * Joins: psa (n=yomode@71.93.19.66)
  658. # [19:28] <jwalden> they don't provide sufficient or useful guarantees for the real world, and if you rely on them for anything you're likely to be let down
  659. # [19:29] <BlueG> so, does that mean we shouldn't use a doctype declaration?
  660. # [19:30] <SadEagle> you should use it to get the browser into strict mode.
  661. # [19:30] <Philip`> You should use a doctype in text/html, because otherwise browsers think you're asking for more bugs
  662. # [19:30] <BlueG> so what is it we are _not_ doing?
  663. # [19:30] * Quits: roc (n=roc@121-72-37-29.dsl.telstraclear.net)
  664. # [19:31] <SadEagle> I believe the idea is that the d-word validation tools are far from sufficient.
  665. # [19:31] <Philip`> (HTML5 currently uses "<!doctype html>", because that has the right effect of making browsers not act buggier, and it doesn't mention or use a DTD at all)
  666. # [19:32] <SadEagle> it's also easy to remember :-)
  667. # [19:33] <Philip`> The old doctype strings aren't just not easy to remember - they are impossible :-)
  668. # [19:35] * Quits: eseidel (n=eseidel@nat/google/x-285b229306ceffdf)
  669. # [19:37] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  670. # [19:37] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  671. # [19:37] * Joins: eseidel (n=eseidel@nat/google/x-1a18c00981b59ad4)
  672. # [19:44] <BlueG> so, how does this work, using html 5? it won't validate as any w3c standard yet, right?
  673. # [19:46] <BlueG> should one use html 5, instead of 4.01, or wait for the standard?
  674. # [19:46] * Quits: eseidel (n=eseidel@nat/google/x-1a18c00981b59ad4)
  675. # [19:47] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 145 (Connection timed out))
  676. # [19:47] <MikeSmith> BlueG - http://hsivonen.iki.fi/doctype/ is worth reading
  677. # [19:47] * Joins: hober (n=ted@unaffiliated/hober)
  678. # [19:48] <MikeSmith> as far as using HTML5 now, see the advice in the "What About HTML5?" section
  679. # [19:49] * Joins: eseidel (n=eseidel@nat/google/x-9296b7fcb0d093a9)
  680. # [20:00] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  681. # [20:00] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  682. # [20:00] <Philip`> BlueG: HTML5 won't become a standard if people don't use it first :-)
  683. # [20:01] <BlueG> hmmm... so, we want to promote standards, but in order to promote the _progress_ of standards, we have to break the current standards?
  684. # [20:01] * BlueG scratches head
  685. # [20:02] <Philip`> It isn't breaking current standards - it's just not following them
  686. # [20:02] <Philip`> Most web pages don't follow the ISO C standard either, but that's okay because they're not meant to be valid C
  687. # [20:02] <BlueG> ok, yea, i guess thats true... still seems like something of an oxymoron... promoting standards by not following them
  688. # [20:02] <BlueG> haha, good point
  689. # [20:05] <SadEagle> Philip`: most C programs aren't 'strictly conforming' with ISO C either, BTW.
  690. # [20:06] <hober> I more-or-less use HTML5 on my site
  691. # [20:06] <hober> Basically, a subset of HTML5: I don't use "new" elements and attributes
  692. # [20:06] <hober> (new being not necessarily "newly defined in a standard," more like "new as in not widely deployed on the web")
  693. # [20:07] <BlueG> hober: so what does that mean practically? does it work well for most users? what can you claim about that kind of markup (as opposed to valid html 4.01 strict, or some such)?
  694. # [20:08] <hober> I haven't received any complaints, if that's what you mean. Also, the site lands in standards mode in the major browsers.
  695. # [20:08] <hober> I'm not sure what you mean about claims.
  696. # [20:09] <BlueG> well, lots of people put buttons or links on their page claiming the validity of their markup, pressumably to promote others to use better markup
  697. # [20:09] <hober> Ahh. No, I don't have any such links on the page.
  698. # [20:13] * Quits: eseidel (n=eseidel@nat/google/x-9296b7fcb0d093a9)
  699. # [20:14] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  700. # [20:15] * Quits: maikmerten (n=maikmert@T78f0.t.pppool.de) (Read error: 110 (Connection timed out))
  701. # [20:16] * Joins: maikmerten (n=maikmert@T6a68.t.pppool.de)
  702. # [20:18] <BlueG> so, if I have content written as xhtml 1.0 and want it to validate as html 4.01 instead, all I should need to do is remove the xml namespace and lang stuff, and change the <br /> type stuff to <br>?
  703. # [20:18] <BlueG> and if I am not interested in validating, I could start adding html 5 features?
  704. # [20:19] <BlueG> what are the most useful features of html 5 that are already widely implemented?
  705. # [20:19] <Philip`> That sounds like it'd probably be sufficient for getting mostly-valid HTML4, and validators can point out any minor issues
  706. # [20:20] <Philip`> You can use the "Highly Experimental" http://html5.validator.nu/ if you want to validate HTML5, though your page might become invalid when the spec changes so you need to be a bit careful
  707. # [20:21] <Philip`> http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers lists some of the implemented things
  708. # [20:23] <SadEagle> Philip`: shall I add things konqueror 4 implements?
  709. # [20:23] * Joins: roc (n=roc@121-72-37-29.dsl.telstraclear.net)
  710. # [20:24] <BlueG> I would certainly be interested in what konqueror 4 implements
  711. # [20:24] <Philip`> SadEagle: Please do :-)
  712. # [20:24] * Philip` wonders if it's able to run Canvex yet...
  713. # [20:25] <SadEagle> Philip`: somewhat. no SVG. what sort of SVG functionality do you need?
  714. # [20:25] * Joins: eseidel (n=eseidel@nat/google/x-70a38107ae02475b)
  715. # [20:26] <Philip`> SadEagle: Hmm, not sure - I just click the buttons in Inkscape and hope browsers can understand it
  716. # [20:27] <SadEagle> Philip`: I mean how do you use it?
  717. # [20:27] * Quits: roc (n=roc@121-72-37-29.dsl.telstraclear.net) (Client Quit)
  718. # [20:27] * Quits: eseidel (n=eseidel@nat/google/x-70a38107ae02475b) (Client Quit)
  719. # [20:28] <Philip`> SadEagle: Er, I'm not quite sure what you mean now
  720. # [20:30] <SadEagle> do you just put them in an <img>, or do somethign fancier?
  721. # [20:31] <Philip`> Oh - they're in an <object> and I do some dynamic setAttribute('transform', '...') on elements inside them
  722. # [20:31] <SadEagle> oh, SVG dom? not soon then :(
  723. # [20:31] <Philip`> (which is a pretty stupid way of implementing an FPS counter, but I wasn't aiming for non-stupidity :-) )
  724. # [20:32] * Joins: roc (n=roc@121-72-37-29.dsl.telstraclear.net)
  725. # [20:32] <SadEagle> I am not sure I want to see that :-)
  726. # [20:32] * Joins: eseidel (n=eseidel@nat/google/x-648f6bf0e054f871)
  727. # [20:33] * Quits: roc (n=roc@121-72-37-29.dsl.telstraclear.net) (Client Quit)
  728. # [20:33] * Quits: eseidel (n=eseidel@nat/google/x-648f6bf0e054f871) (Client Quit)
  729. # [20:37] * Quits: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  730. # [20:37] * Joins: eseidel (n=eseidel@nat/google/x-7f450830da40c57a)
  731. # [20:41] * Quits: maikmerten (n=maikmert@T6a68.t.pppool.de) ("Leaving")
  732. # [20:44] * Quits: eseidel (n=eseidel@nat/google/x-7f450830da40c57a) (Read error: 104 (Connection reset by peer))
  733. # [20:44] * Joins: eseidel (n=eseidel@nat/google/x-9aac47e3664aea78)
  734. # [20:56] * Joins: jgraham (n=james@81-86-212-85.dsl.pipex.com)
  735. # [20:57] * Quits: eseidel (n=eseidel@nat/google/x-9aac47e3664aea78)
  736. # [21:01] * Quits: billmason (n=billmaso@ip129.unival.com) (Read error: 104 (Connection reset by peer))
  737. # [21:07] * Joins: grimboy (n=grimboy@78.150.249.220)
  738. # [21:11] <takkaria> gsnedders: well, there's an independent small open-source browser called netsurf that's just updated their cookie support, I'm not sure what kind of feedback you'd want off them but I could pass messages along
  739. # [21:40] <gsnedders> is there any way to get back to a DOM from a tree walker (in html5lib)?
  740. # [21:41] * Quits: grimboy (n=grimboy@78.150.249.220) (Read error: 110 (Connection timed out))
  741. # [21:42] <gsnedders> takkaria: in a world where everyone has to remain compat. with the guy with the largest marketshare, not much — probably just comments on what I generally send out (which will be sent to whatwg@whatwg.org among other places)
  742. # [21:46] * Quits: anne-mibbit (i=5352d922@gateway/web/ajax/mibbit.com/x-fb2e6b8e167828f2) ("http://www.mibbit.com ajax IRC Client")
  743. # [21:47] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  744. # [22:00] * Joins: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk)
  745. # [22:09] <Hixie> hsivonen: mail me about the ebcdic stuff
  746. # [22:10] <Hixie> Philip`: i changed the code based on your earlier comments and haven't seen your edgedetect.html -- let me know when i regen the spec if you like the new code
  747. # [22:11] <Hixie> "case 12: case 12:" fixed
  748. # [22:12] <Hixie> regarding the @font-face test, safari passes it, but fails the positioning test
  749. # [22:12] <Hixie> opera fails the font-face part but passes the positioning part (not that you'd know it given the mess that's going on around it)
  750. # [22:12] <Hixie> and firefox fails both
  751. # [22:13] <SadEagle> Hixie: is it intentional that the treewalker testcases don't seem to test the really nasty stuff?
  752. # [22:13] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  753. # [22:13] <Hixie> what's the nasty stuff?
  754. # [22:13] <SadEagle> filtering of non-leafs
  755. # [22:13] <Hixie> if you can come up with something that matches the conditions listed on http://ln.hixie.ch/ i'd be happy to add it
  756. # [22:14] <Hixie> however i don't recall finding any bugs with the non-leafs filtering
  757. # [22:14] <SadEagle> (reading). I have to make a bunch of TC's anyway
  758. # [22:14] <jwalden> Hixie: test 5/instructions.inc got out of sync again
  759. # [22:14] <SadEagle> Hixie: safari should be completely broken with that if my code reading is right
  760. # [22:15] <Hixie> jwalden: heh, i went back to what i had before and again forgot to update the test :-)
  761. # [22:15] <Hixie> SadEagle: http://www.hixie.ch/tests/evil/acid/003/competition/ can help you write a test to check
  762. # [22:15] <SadEagle> Hixie: thanks
  763. # [22:16] <jwalden> acid3 points for everyone!
  764. # [22:16] <jwalden> if you implement treewalker correctly, that is
  765. # [22:16] * SadEagle goes back to debugging treewalker :-)
  766. # [22:16] <Hixie> k, gotta go catch a bus
  767. # [22:16] <Hixie> bbiab
  768. # [22:27] * Joins: kingryan (n=kingryan@dsl092-219-050.sfo1.dsl.speakeasy.net)
  769. # [22:42] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  770. # [22:55] * Joins: peepo (n=Jay@host217-42-95-198.range217-42.btcentralplus.com)
  771. # [22:56] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  772. # [22:56] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  773. # [23:01] <Philip`> Hixie: The "var i = 0;" should be removed
  774. # [23:03] <Philip`> Otherwise I think it looks reasonable
  775. # [23:05] * Joins: weinig (n=weinig@17.203.15.140)
  776. # [23:12] * Joins: tndH_ (i=Rob@adsl-87-102-43-39.karoo.KCOM.COM)
  777. # [23:12] * Quits: tndH (i=Rob@adsl-87-102-83-222.karoo.KCOM.COM) (Read error: 104 (Connection reset by peer))
  778. # [23:12] * tndH_ is now known as tndH
  779. # [23:17] * Joins: weinig_ (n=weinig@17.203.15.140)
  780. # [23:17] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 104 (Connection reset by peer))
  781. # [23:17] <jruderman> how is the acid3 competition going?
  782. # [23:23] * Quits: phsiao (n=shawn@nat/ibm/x-c7bc1de0ed400dd9)
  783. # [23:35] * Quits: csarven (n=nevrasc@on-irc.csarven.ca) (Remote closed the connection)
  784. # [23:39] <jgraham__> gsnedders: Re: html5lib, from memory it's not trivial
  785. # [23:40] <jgraham__> Although I make no promises about the quality of my memory on this point
  786. # [23:41] <gsnedders> sux.
  787. # [23:41] <gsnedders> jgraham__: can I buy a memory upgrade for you?
  788. # [23:41] <jgraham__> But it shouldn't be hard to implement because the tokens a treewalker produces look like the ones the tokenizer produces, so you just use the treewalker as a tokenizer
  789. # [23:42] <jgraham__> I'd like a memory upgrade. And more registers
  790. # [23:43] <gsnedders> jgraham__: what arch are you based on?
  791. # [23:43] <gsnedders> s/arch/arch./
  792. # [23:43] <jgraham__> Homo Sapiens/Male
  793. # [23:45] <gsnedders> jgraham__: Homo and Sapiens/Male?
  794. # [23:50] <jgraham__> All one term. Do parentheses help?: (Homo sapiens)/Male It's a fundamentally mammalian arch. although it still suffers of many of the design flaws of earlier models in its lineage. Many people are of the opinion that a ground-up redesign is the only way forward, but current users can't be persuaded to make the upgrade
  795. # Session Close: Sat Jan 19 00:00:00 2008

The end :)