/irc-logs / freenode / #whatwg / 2007-05-15 / end

Options:

  1. # Session Start: Tue May 15 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:05] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  4. # [00:05] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  5. # [00:08] * Joins: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  6. # [00:10] * Quits: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com) (Client Quit)
  7. # [00:13] <Hixie> wow.
  8. # [00:13] <Hixie> talk about a lack of interoperability
  9. # [00:13] <Hixie> http://www.hixie.ch/tests/adhoc/html/canvas/037.html
  10. # [00:16] <Hixie> i have three browsers and SIX different renderings
  11. # [00:16] <Philip`> And the spec gives a seventh rendering, and potentially an eighth if you interpret it differently ;-)
  12. # [00:17] * Joins: aroben (n=adamrobe@17.203.15.208)
  13. # [00:17] * Quits: aroben (n=adamrobe@17.203.15.208) (Remote closed the connection)
  14. # [00:17] <Hixie> the original spec gives a 7th
  15. # [00:17] <Hixie> and i recently changed it to an 8th, yes
  16. # [00:17] * zcorpan_ writes some test cases on <body bgcolor> parsing
  17. # [00:17] <Hixie> sweet kittens what a mess
  18. # [00:18] <Hixie> ok let's see
  19. # [00:18] <Hixie> opera is definitely buggy
  20. # [00:18] <Hixie> safari 2 is definitely buggy
  21. # [00:18] <Philip`> In the original spec I couldn't tell whether it was meant to draw a cone between offsets 0 and 1, or between -infinity and +infinity
  22. # [00:19] <Hixie> well it definitely has to go through the two circles you specify in the createRadialGradient method
  23. # [00:19] <Hixie> and opera and safari 2 don't do that
  24. # [00:20] * Quits: jgraham (n=jgraham@85-210-7-238.dsl.pipex.com) ("Ex-Chat")
  25. # [00:20] <Hixie> nor does camino as far as i can tell
  26. # [00:20] <Hixie> i don't understand where camino gets its rendering from
  27. # [00:20] <Philip`> Oh, I noticed that problem in Opera but not in the cases I tried in Safari
  28. # [00:20] <Hixie> this leaves firefox 2 linux, minefield mac, and webkit trunk as my potentially correct renderings
  29. # [00:20] <Philip`> (Konqueror 3.8 is utterly broken with radial gradients too)
  30. # [00:21] <Hixie> minefield mac ignores the first stop so that's wrong...
  31. # [00:21] <Hixie> firefox 2 linux creates two cones, one truncated
  32. # [00:21] <Hixie> that's gotta be wrong
  33. # [00:22] <Hixie> so that leaves webkit trunk
  34. # [00:22] <Hixie> which creates an infinite cone
  35. # [00:22] <Hixie> let's test webkit trunk with a cone that ends finitely
  36. # [00:23] <Hixie> it works
  37. # [00:23] <Hixie> ok
  38. # [00:23] <Hixie> that wins
  39. # [00:25] <Philip`> "minefield mac ignores the first stop" - I see all four colours in 037 with Minefield on Linux
  40. # [00:25] <Hixie> yeah i expect the linux one has a less buggy cairo
  41. # [00:26] <Philip`> Ah, okay - I think they're all using the same Cairo version, but presumably different backend code within Cairo
  42. # [00:27] <Hixie> holy crap
  43. # [00:27] <Hixie> minefield on linux gives us a 7th rendering
  44. # [00:38] <jruderman> on mac, i see a green-blue gradient, and some magenta, and some horribly aliased borders. i don't see any black or yellow.
  45. # [00:38] <Philip`> Given that Cairo doesn't even bother to do this consistently between platforms or between versions, it seems to be a case that doesn't come up very often in practice, so nobody will mind what the output is as long as it's consistent
  46. # [00:38] <jruderman> (firefox trunk)
  47. # [00:39] <Hixie> jruderman: the existence of the green-blue gradient is the only constant in the results
  48. # [00:39] <Hixie> well, except safari 2, which just draws black
  49. # [00:40] <jruderman> hah
  50. # [00:40] <Hixie> (the test description is wrong)
  51. # [00:40] <jruderman> i'm surprised, i thought canvas was simple and already consistent across browsers
  52. # [00:40] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) (Read error: 104 (Connection reset by peer))
  53. # [00:40] <jruderman> oh
  54. # [00:40] * Joins: KevinMarks (n=KevinMar@207.47.11.9.static.nextweb.net)
  55. # [00:40] <Hixie> jruderman: it's surprisingly consistent in the areas i wrote good spec test for
  56. # [00:41] <jruderman> "Hixie has NFI how the test below should render."
  57. # [00:41] <Philip`> Oh, Safari 2 just doesn't do gradients in fillRect - you can do rect() fill() instead and it'll work more usefully
  58. # [00:41] <jruderman> Hixie: hehe
  59. # [00:41] <Philip`> (in case you want to test its actual gradient rendering)
  60. # [00:41] <Hixie> Philip`: yeah
  61. # [00:41] <jruderman> what's with the jagged diagonal borders?
  62. # [00:42] <Hixie> what's a good third dimension variable name other than t, r and z?
  63. # [00:42] <Philip`> jruderman: It's consistent in the obvious cases, until you try doing something non-trivial and find different bugs in every variable :-)
  64. # [00:42] <Philip`> Uh
  65. # [00:42] <Philip`> s/variable/browser/
  66. # [00:43] <Philip`> (I don't know where that word came from)
  67. # [00:43] <Hixie> probably came from you reading what i just wrote :-P
  68. # [00:43] <jruderman> Hixie: w?
  69. # [00:43] <Hixie> w might work
  70. # [00:43] <Hixie> i was thinking s
  71. # [00:43] <jruderman> Hixie: h, for height?
  72. # [00:43] <Philip`> alpha?
  73. # [00:43] <Hixie> but w is good
  74. # [00:43] <Hixie> alpha might work too
  75. # [00:43] <Hixie> alpha is better actually yeah
  76. # [00:44] <jruderman> Hixie: a, for altitude, and to confuse Philip` ?
  77. # [00:44] <bewest> d for depth?
  78. # [00:44] <Hixie> it's not a physical dimension
  79. # [00:44] <Philip`> Lowercase omega, to confuse jruderman?
  80. # [00:44] <Hixie> (it's a position along an imaginative line)
  81. # [00:44] <Hixie> ooo
  82. # [00:44] <Hixie> omega
  83. # [00:44] <Hixie> omega it is
  84. # [00:44] <bewest> heh
  85. # [00:45] <Hixie> (or "wibble" as we used to call it at university)
  86. # [00:46] <Philip`> I'm alright until people start using xi and zeta, and then I get totally confused
  87. # [00:55] <zcorpan_> http://simon.html5.org/test/html/parsing/color-attributes/001.htm
  88. # [00:58] <zcorpan_> can anyone test that in safari?
  89. # [00:59] <Hixie> hold on
  90. # [00:59] <zcorpan_> just see if there are any with #00ff00
  91. # [00:59] <Hixie> nope
  92. # [00:59] <zcorpan_> interesting
  93. # [01:00] <Hixie> <body>, <head>, <html> are blank; <isindex> is null
  94. # [01:00] <Hixie> on trunk
  95. # [01:01] <Hixie> safari 2 <noembed>, <noframes>, <nolayer>, <noscript> are also blank
  96. # [01:01] <Hixie> and <isindex> is not null
  97. # [01:03] <Hixie> ok, i have a new, "more mathematical" definition for radial gradients
  98. # [01:03] <Hixie> let's fix these tests to match
  99. # [01:04] <Philip`> "more mathematical" = "more Greek letters"?
  100. # [01:04] <zcorpan_> what happens with http://simon.html5.org/test/html/parsing/color-attributes/002.htm ?
  101. # [01:04] <Hixie> Philip`: yup!
  102. # [01:04] <Hixie> zcorpan_: trunk: lime, xxff
  103. # [01:04] <Hixie> s2 same
  104. # [01:05] <zcorpan_> ah, so it's not handled in the parser like in other browsers
  105. # [01:05] <zcorpan_> ok
  106. # [01:07] <zcorpan_> hm, wonder what is most sane to do here. perhaps just the rendering section should say how to interpret bgcolor values or something
  107. # [01:07] * Quits: KevinMarks (n=KevinMar@207.47.11.9.static.nextweb.net) (Read error: 104 (Connection reset by peer))
  108. # [01:07] * Joins: KevinMarks (n=KevinMar@207.47.11.9.static.nextweb.net)
  109. # [01:08] <Hixie> zcorpan_: whatcha testing?
  110. # [01:08] <zcorpan_> <body bgcolor=xxff>
  111. # [01:08] <Philip`> Do you know how many attributes this applies to? (At least <font color> seems to be handled the same, but I don't know about any other colour attributes)
  112. # [01:08] <zcorpan_> parsed as <body bgcolor=#00ff00> in ie7, gecko and opera
  113. # [01:08] <Hixie> zcorpan_: i want to have the spec say that the content attributes always match the markup
  114. # [01:09] <Hixie> zcorpan_: though the DOM attributes might differ
  115. # [01:09] <Hixie> zcorpan_: and the processing might differ a lot
  116. # [01:09] <Hixie> e.g. as in this case
  117. # [01:09] <zcorpan_> Hixie: ok
  118. # [01:09] <Hixie> hopefully that won't break too much
  119. # [01:09] <Hixie> but who knows :-/
  120. # [01:09] <Hixie> we'll have to find out
  121. # [01:09] <Hixie> possibly the hard way
  122. # [01:10] <zcorpan_> this doesn't have to be handled in the parser, given that safari doesn't
  123. # [01:10] <Hixie> yeah
  124. # [01:10] <Hixie> that was my assumption
  125. # [01:10] <Hixie> people don't generally read back their broken content, in my experience
  126. # [01:10] <Hixie> for presentational stuff, at least
  127. # [01:10] <zcorpan_> indeed
  128. # [01:11] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  129. # [01:17] * Hixie introduces www-html to modern-day spec writing
  130. # [01:21] <Dashiva> The culture shock will kill them
  131. # [01:22] <Hixie> "I demand to see [multi-million page studies] for *every* single element/attribute..."
  132. # [01:24] * Quits: KevinMarks (n=KevinMar@207.47.11.9.static.nextweb.net) ("The computer fell asleep")
  133. # [01:28] <Philip`> Hixie: The currently online algorithm doesn't seem to work at all if you do createRadialGradient(0, 0, 10, 0, 0, 20) because it will start by drawing an infinite circle with the colour at offset 1, then draw nothing in any further steps, when it needs to be drawing an actual gradient pattern instead
  134. # [01:28] <Hixie> a solid colour is exactly what i'd expect for createRadialGradient(0, 0, 10, 0, 0, 20)
  135. # [01:29] <Hixie> since the two circles are completely inside one another and the end one totally overlaps the start one
  136. # [01:29] <Philip`> Oh - that's not what I'd expect, and it's not what any browser appears to give
  137. # [01:29] <Hixie> uri?
  138. # [01:29] <Philip`> I'd expect it to just do a smooth gradient between the two circles I told it to draw a smooth gradient between
  139. # [01:30] <Hixie> i agree, except that one of those two circles is completely on top of the gradient
  140. # [01:30] <Philip`> The top line in http://canvex.lazyilluminati.com/misc/radial/examples.html
  141. # [01:30] <Hixie> createRadialGradient(0, 0, 20, 0, 0, 10) will give you what you describe
  142. # [01:31] <Hixie> (wtf is firefox3 doing)
  143. # [01:32] <Philip`> Which one? FF3a3 (on Windows) is really not doing very well, but that was a strangely broken of Cairo and they've updated since then
  144. # [01:32] <Hixie> top picture of http://canvex.lazyilluminati.com/misc/radial/o-firefox3a3.png is the one that made me say wtf
  145. # [01:32] <Philip`> (FF3a4 appears to match on Windows and Linux)
  146. # [01:33] <Philip`> It looks like they kind of gave up on the whole idea of drawing radial gradients, and thought a coloured blob would be close enough
  147. # [01:33] <Hixie> i don't understand how you can have r0 > r1 and r0 < r1 both have a gradient, while still having the end circle filled with the end colour
  148. # [01:33] <Philip`> You don't have the end circle filled with the end colour
  149. # [01:34] * Quits: kingryan (n=kingryan@corp.technorati.com) (Remote closed the connection)
  150. # [01:34] <Philip`> (except when the circles aren't entirely overlapping)
  151. # [01:34] * Joins: kingryan (n=kingryan@corp.technorati.com)
  152. # [01:34] <Hixie> what would you draw then? just the circumferences?
  153. # [01:35] <Philip`> It doesn't seem very useful for cRG(x,y, 10, x,y, 20) to give you a solid colour - if you wanted that, you wouldn't both with a gradient at all - and it requires more effort for people to work out which way around the arguments should go when all they want is a visible gradient
  154. # [01:35] * Quits: kingryan (n=kingryan@corp.technorati.com) (Client Quit)
  155. # [01:36] <Hixie> i really don't like the idea of having a condition under which the end circle is filled or not.
  156. # [01:37] <Philip`> It works sensibly (like WebKit and FF2) if you just draw circumferences, or if you start drawing filled circles from the smaller towards the larger (if not overdrawing previously-drawn bits)
  157. # [01:37] <Philip`> ...except only when the smaller circle is contained within the larger circle
  158. # [01:37] <Hixie> can you describe the algorithm without using the words "except" or "but"?
  159. # [01:40] * Philip` tries to work out what he was thinking of
  160. # [01:43] <Philip`> The bit at the bottom of http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011186.html is what I think 'works' (matching the "proposed spec" column, which is mostly like WebKit) - just draw circumferences, with circles near +infinity drawn on top of circles near -infinity
  161. # [01:44] <Hixie> have i replied to that mail?
  162. # [01:44] <Philip`> I don't think so
  163. # [01:45] <Hixie> i wonder where it is
  164. # [01:45] <Hixie> it's not in my canvas pile
  165. # [01:45] <Philip`> Oh, odd
  166. # [01:46] <Hixie> oh
  167. # [01:46] <Hixie> gmail thought it was spam
  168. # [01:46] <Hixie> go figure
  169. # [01:46] <Philip`> Oops
  170. # [01:46] <Hixie> ok, rescued it
  171. # [01:46] <Philip`> If I thought you hadn't seen it, I would have pointed it out earlier :-)
  172. # [01:47] * Hixie reads
  173. # [01:47] <Hixie> :-)
  174. # [01:48] <Hixie> this e-mail is awesome
  175. # [01:48] <Hixie> i must reply to it and fix the spec appropriately!
  176. # [01:55] <Hixie> well there's irony for you. i write a testcase: http://www.hixie.ch/tests/adhoc/html/canvas/040.html
  177. # [01:55] <Hixie> ...and the only browser that renders the gradient correctly renders the control image incorrectly
  178. # [01:56] <Hixie> ok fixed the test
  179. # [01:57] * Joins: kingryan (n=kingryan@corp.technorati.com)
  180. # [01:59] <Dashiva> "Or have someone officially redefined HTML as a presentational language while I was looking the other way?"
  181. # [01:59] <Dashiva> I'm tempted to say "Yes" and point to the internet
  182. # [01:59] <Hixie> or "hard to say, how long have you been away?"
  183. # [02:06] * Philip` finds that Opera and Firefox don't apply globalAlpha to gradients
  184. # [02:06] * Philip` adds to list of things to test properly
  185. # [02:06] <Philip`> (At least Safari does it properly)
  186. # [02:08] * Joins: csarven- (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  187. # [02:09] <Philip`> (Opera doesn't do globalAlpha on images either, which was annoying since it messed up my game's lighting :-( )
  188. # [02:17] * Joins: KevinMarks (n=KevinMar@207.47.11.9.static.nextweb.net)
  189. # [02:26] <Hixie> it's amusing how gradients aren't anti-aliased in browsers
  190. # [02:26] <Hixie> radial gradients
  191. # [02:32] <Philip`> They don't antialias linear gradients either
  192. # [02:32] <Hixie> ah
  193. # [02:32] <Hixie> sucky
  194. # [02:33] <othermaciej> smooth gradients need dithering, not antialiasing
  195. # [02:33] <othermaciej> (at least ones that show visible banding)
  196. # [02:33] <othermaciej> ones that are intentionally banded I'd guess are a bit of an unexpected case
  197. # [02:34] <Philip`> Unexpected cases are what make specifying <canvas> fun :-)
  198. # [02:36] * Quits: csarven- (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  199. # [02:41] * Quits: KevinMarks (n=KevinMar@207.47.11.9.static.nextweb.net) ("The computer fell asleep")
  200. # [02:42] * zcorpan_ recorded results at http://simon.html5.org/test/html/parsing/color-attributes/
  201. # [02:47] * Quits: tantek (n=tantek@corp.technorati.com)
  202. # [02:48] * Joins: tantek (n=tantek@corp.technorati.com)
  203. # [02:50] * Quits: zcorpan_ (n=zcorpan@84-216-41-242.sprayadsl.telenor.se) (Read error: 104 (Connection reset by peer))
  204. # [02:51] * Joins: zcorpan_ (n=zcorpan@84-216-41-242.sprayadsl.telenor.se)
  205. # [02:56] * Quits: kingryan (n=kingryan@corp.technorati.com) (Read error: 104 (Connection reset by peer))
  206. # [02:56] * Joins: kingryan (n=kingryan@corp.technorati.com)
  207. # [03:01] <Hixie> othermaciej: http://hixie.ch/tests/adhoc/html/canvas/040.html shows the need for anti-aliasing along the top and bottom
  208. # [03:01] <Hixie> othermaciej: the gradient has an edge
  209. # [03:02] <Hixie> i wonder how i can write a good test for checking that browsers don't do premultiplied alpha interpolation
  210. # [03:02] <Philip`> Use getImageData to check the pixel value?
  211. # [03:03] <Hixie> that's not reliable
  212. # [03:03] <Hixie> ideally i just want a visual test
  213. # [03:03] <Philip`> Oh, true, particularly since I think Firefox returns premultiplied components from getImageData
  214. # [03:04] <Hixie> why did you suggest this?:
  215. # [03:04] <Hixie> > * If one of the start circle and end circle is enclosed within the
  216. # [03:04] <Hixie> > other circle, and their circumferences touch in at least one point,
  217. # [03:04] <Hixie> > then the gradient must be rendered as the color at offset 0.
  218. # [03:07] <Philip`> Could draw a gradient from rgba(255,255,255,1) to rgba(0,0,0,0), and if it's being interpolated in premultiplied colour space then it'll be white all the way along (with varying alpha), otherwise it'll be grey in the middle
  219. # [03:08] <Hixie> yeah, i'm actually doing that :-)
  220. # [03:08] <Hixie> http://hixie.ch/tests/adhoc/html/canvas/041.html
  221. # [03:10] <Philip`> http://canvex.lazyilluminati.com/misc/radial/examples.html - 4th, 5th and 6th rows - if you just drew the infinite number of circles to make a cone, the edge of the cone would intersect the viewer's eye, so it wouldn't do colouring over the part of the background that's on the outside of that edge
  222. # [03:11] <Philip`> Or the simpler case is when the two circles are exactly equal, and you're looking down the centre of an infinite cylinder whose edges have zero width, so it wouldn't draw anything at all
  223. # [03:12] <Hixie> yeah for r0=r1 i see the problem
  224. # [03:12] <Hixie> i don't get the problem for the touching != case though
  225. # [03:12] <Hixie> assuming we just draw the circumferences
  226. # [03:13] <Hixie> you still get a cone with zero and infinite radii
  227. # [03:14] * Joins: yod (n=ot@dhcp-247-204.mag.keio.ac.jp)
  228. # [03:15] * Quits: kingryan (n=kingryan@corp.technorati.com)
  229. # [03:17] <Philip`> When the two circles touch at one point, then all the circles made by interpolating radius and centre will also touch at that same point, and so the areas on the outside of the edge at that point will never be painted because no circle ever extends out in that direction
  230. # [03:18] <Hixie> so?
  231. # [03:18] <Hixie> that's the same as in the not overlapping case
  232. # [03:18] <Hixie> you get non-painted areas
  233. # [03:18] <Hixie> it's more useful than all the same colour, at least
  234. # [03:21] <Philip`> You'd get half the area painted with the colour at offset 1, and the other half not painted at all, which I suppose isn't worse than painting the whole area with the colour at offset 0; but nobody seems to implement it that way now, and I'd guess they have reasons for doing that (like it being easier, and nobody really caring what the output is)
  235. # [03:21] <Hixie> and you'd get a gradient
  236. # [03:21] <Hixie> tiny one
  237. # [03:21] <Hixie> but a gradient nonetheless
  238. # [03:22] * Quits: jdandrea (n=jdandrea@ool-44c0a58f.dyn.optonline.net) (heinlein.freenode.net irc.freenode.net)
  239. # [03:22] * Quits: bzed (n=bzed@dslb-084-059-096-203.pools.arcor-ip.net) (heinlein.freenode.net irc.freenode.net)
  240. # [03:22] * Quits: laug (n=laug@poy.chewa.net) (heinlein.freenode.net irc.freenode.net)
  241. # [03:22] * Quits: didymos (i=jho@rapwap.razor.dk) (heinlein.freenode.net irc.freenode.net)
  242. # [03:22] * Quits: bewest (n=ben@httpcraft/bewest) (heinlein.freenode.net irc.freenode.net)
  243. # [03:22] * Quits: deltab (n=deltab@82-46-154-93.cable.ubr02.smal.blueyonder.co.uk) (heinlein.freenode.net irc.freenode.net)
  244. # [03:22] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (heinlein.freenode.net irc.freenode.net)
  245. # [03:22] * Quits: moeffju (i=moeffju@ubermutant.net) (heinlein.freenode.net irc.freenode.net)
  246. # [03:22] * Quits: dolphinling (n=chatzill@rbpool1-4.shoreham.net) (heinlein.freenode.net irc.freenode.net)
  247. # [03:22] * Quits: tantek (n=tantek@corp.technorati.com) (heinlein.freenode.net irc.freenode.net)
  248. # [03:22] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com) (heinlein.freenode.net irc.freenode.net)
  249. # [03:22] * Quits: ianloic (n=ian@71.5.56.162.ptr.us.xo.net) (heinlein.freenode.net irc.freenode.net)
  250. # [03:22] * Quits: Lachy (n=Lachlan@203-217-95-91.dyn.iinet.net.au) (heinlein.freenode.net irc.freenode.net)
  251. # [03:22] * Quits: hays (n=hays@pool-138-88-199-16.res.east.verizon.net) (heinlein.freenode.net irc.freenode.net)
  252. # [03:22] <Philip`> Oops, yes, you'd get the normal gradient inside the circle, and then half the background filled with colour 1
  253. # [03:23] <Hixie> right
  254. # [03:23] * Joins: hays (n=hays@pool-138-88-199-16.res.east.verizon.net)
  255. # [03:24] <othermaciej> Hixie: yeah, I looked at that, it does look like the edges of the gradient area at least should be antialiased
  256. # [03:25] <Philip`> It might be a nasty edge case to implement (but I don't know at all so I'm just guessing wildly) - perhaps it'd be easier to pretend the smaller circle had been nudged very slightly inwards, so that they weren't right on the edge any more, and then you'd just draw everything as normal (like what Firefox 2 does, minus the small buggy bits)
  257. # [03:26] <Hixie> i hate exceptions :-)
  258. # [03:26] <Hixie> to me it's just the step between them being completely concentric and them being non-overlapping
  259. # [03:27] <Hixie> or rather, to them being overlapping-or-non-contentric
  260. # [03:27] <Hixie> concentric
  261. # [03:27] <Hixie> and that happens to have a weird edge case
  262. # [03:27] <Philip`> I expect the implementors hate them more, particularly when they have to implement the exceptional case in a complex way just to be theoretically purer :-)
  263. # [03:27] <Hixie> i don't see how this is a complex case
  264. # [03:27] <Hixie> but then i don't know how radial gradients are normally painted
  265. # [03:27] <Hixie> so...
  266. # [03:28] <Philip`> Because nobody implements it by actually drawing an infinite number of circles
  267. # [03:28] <Hixie> sure
  268. # [03:28] <Philip`> but then I don't know how they are implemented either
  269. # [03:28] <Hixie> but how do they paint them?
  270. # [03:28] <othermaciej> with science
  271. # [03:28] <Hixie> btw is there some way to make something appear when alpha is premultiplied that won't appear when alpha isn't premultiplied, that you can think of?
  272. # [03:28] <othermaciej> computer science
  273. # [03:29] <othermaciej> what do you mean by alpha being premultiplied?
  274. # [03:29] <othermaciej> in what place?
  275. # [03:29] <Hixie> gradient interpolation
  276. # [03:29] <othermaciej> what's your expectation of the difference - less fine detail in the gradient?
  277. # [03:29] <Hixie> hixie.ch/www/tests/adhoc/html/canvas/041.html
  278. # [03:30] <Hixie> er http://www.hixie.ch/tests/adhoc/html/canvas/041.html
  279. # [03:30] <othermaciej> (I'm assuming that you don't mean the color stops are treated as being premultiplied by the alpha already, as that would look very different)
  280. # [03:30] <Philip`> (Is there a guarantee that the load event won't be called after setting .src and before setting .onload?)
  281. # [03:31] <Hixie> othermaciej: as i just learnt, if you interpolate from 255,255,255,1.0 to 0,0,0,0, you'll get a different rendering if you do it by premultiplying alpha than if you won't
  282. # [03:32] <Hixie> Philip`: i think i specced it such that setting 'src' doesn't fire the event synchronously, ever
  283. # [03:32] <Hixie> Philip`: and events can't otherwise fire when code is running
  284. # [03:32] <othermaciej> what's an example of a browser that does premultiply?
  285. # [03:32] <Hixie> there are non, to my knowledge
  286. # [03:32] <Hixie> none
  287. # [03:33] <Philip`> Cairo uses premultiplied alpha internally, but does the gradient interpolation correctly as equivalent to linear in non-premultiplied components
  288. # [03:33] <othermaciej> oh I see
  289. # [03:33] <othermaciej> if you premultiply and then treat the interoplated colors as premultiplied, it would be all white
  290. # [03:34] <Philip`> like its premultiplied components go (255,255,255,1.0), (64,64,64,0.5), (0,0,0,0.0), rather than going linearly
  291. # [03:34] <Philip`> (If I remember correctly, Opera uses non-premultiplied internally, but I could be totally wrong)
  292. # [03:35] <Hixie> so i'm looking for something which would show something when you're premultiplying
  293. # [03:35] <Hixie> but wouldn't if you do it right
  294. # [03:35] <othermaciej> CoreGraphics uses premultiplied pixel formats for images, but I guess not in this case
  295. # [03:35] <othermaciej> Hixie: if you made the text grey in your 041.html case that would hold, no?
  296. # [03:36] <Hixie> how do you mean?
  297. # [03:36] <othermaciej> Hixie: well, right now it shows something when *not* premultiplied, but doesn't when you *are* premultiplied
  298. # [03:36] <othermaciej> because the premultiplied gradient is white instead of grey
  299. # [03:36] <Philip`> data:text/html,<canvas id=c></canvas><script>c=document.getElementById('c');ctx=c.getContext('2d');ctx.fillStyle='rgba(12,34,56,0.01)';ctx.fillRect(0,0,1,1);alert(c.getContext('opera-2dgame').getPixel(0,0))</script> - aha, Opera stores non-premultiplied, else it would lose all the precision in the rgb components
  300. # [03:37] <othermaciej> so you could swap the text color to match the other way
  301. # [03:37] <Hixie> othermaciej: the text colour wouldn't be a solid colour then
  302. # [03:38] <Hixie> oh well, i'll just have the positive test, doesn't really matter since everyone passes anyway
  303. # [03:39] <othermaciej> it might only be practically invisible
  304. # [03:40] <Hixie> you'd be surprised how picky QA people can be
  305. # [03:40] <Hixie> like, they complain that "This line should be green" when the line has a green background is a failure because the line isn't green, its background is green.
  306. # [03:40] <Hixie> or they complain that the pixel rounding on the nose of Acid2 is wrong
  307. # [03:41] * Quits: othermaciej (i=mjs@nat/apple/x-339a92b0dff40a07)
  308. # [03:41] <Philip`> Perhaps you could draw a gradient with its endpoints millions of pixels apart, so the visible part in the center is a solid colour
  309. # [03:41] <Philip`> and then make the text match that colour
  310. # [03:42] <Hixie> that has the problem with reliability that getPixelData has
  311. # [03:42] <Hixie> no worries
  312. # [03:42] <Hixie> one test is fine
  313. # [03:44] * Quits: zcorpan_ (n=zcorpan@84-216-41-242.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  314. # [03:44] * Joins: tantek (n=tantek@corp.technorati.com)
  315. # [03:44] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  316. # [03:44] * Joins: ianloic (n=ian@71.5.56.162.ptr.us.xo.net)
  317. # [03:44] * Joins: Lachy (n=Lachlan@203-217-95-91.dyn.iinet.net.au)
  318. # [03:45] * Joins: dolphinling (n=chatzill@rbpool1-4.shoreham.net)
  319. # [03:45] * Joins: jdandrea (n=jdandrea@ool-44c0a58f.dyn.optonline.net)
  320. # [03:45] * Joins: bzed (n=bzed@dslb-084-059-096-203.pools.arcor-ip.net)
  321. # [03:45] * Joins: bewest (n=ben@httpcraft/bewest)
  322. # [03:45] * Joins: didymos (i=jho@rapwap.razor.dk)
  323. # [03:45] * Joins: laug (n=laug@poy.chewa.net)
  324. # [03:45] * Joins: deltab (n=deltab@82-46-154-93.cable.ubr02.smal.blueyonder.co.uk)
  325. # [03:45] * Joins: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  326. # [03:45] * Joins: moeffju (i=moeffju@ubermutant.net)
  327. # [03:57] * Quits: tantek (n=tantek@corp.technorati.com)
  328. # [04:10] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  329. # [04:28] * Joins: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  330. # [04:32] * Quits: bzed (n=bzed@dslb-084-059-096-203.pools.arcor-ip.net) ("Leaving")
  331. # [04:36] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  332. # [04:47] <Philip`> "If multiple stops are placed at the same place on a gradient, they must be placed in the order added" - that sounds a bit awkward with so many 'place'; maybe "If multiple stops are added at the same offset on a gradient, they must be placed in the order added"?
  333. # [04:51] <Philip`> "draw the circumference of the circle with radius of radius r(\omega)" - repetition
  334. # [04:52] <Philip`> "If the two circles overlap, the effect is as if the second (end) circle is painted on top of the first circle. The end circle is always filled with the color of the last stop." - I think both those sentences are wrong with the new definition
  335. # [05:09] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  336. # [05:26] * Quits: yod (n=ot@dhcp-247-204.mag.keio.ac.jp) ("Leaving")
  337. # [05:35] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  338. # [06:03] * Quits: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  339. # [06:11] * Joins: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  340. # [06:33] * Quits: jdandrea (n=jdandrea@ool-44c0a58f.dyn.optonline.net)
  341. # [06:34] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("Leaving")
  342. # [06:56] * Joins: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net)
  343. # [07:00] <Hixie> Philip`: can you send mail with those? i'll look at them when i next do editing work (prolly tomorrow)
  344. # [07:01] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  345. # [07:17] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  346. # [07:22] <Lachy> Hixie, thanks for the stats
  347. # [07:22] <Lachy> would it be fair to say that 0.05% is widely used, given that for 1 billion, that equals about 50 million pages?
  348. # [07:23] <Hixie> it's 0.05% used
  349. # [07:23] <Hixie> i can't tell you if that's "widely" or not
  350. # [07:23] <Hixie> depends on the context
  351. # [07:24] <Lachy> fair enough. I can just imagine the response when I send those stats to the list being "that's an insignificant amount, we can drop those elements!"
  352. # [07:24] <Hixie> well that's why i gave the other elements as context
  353. # [07:24] <Hixie> <blink>, <ruby>, <cite>, <dfn>
  354. # [07:24] <Lachy> yeah
  355. # [07:26] <Hixie> for deciding of it should be in the spec or not, one page is enough, if the page is, say, cnn.com
  356. # [07:27] <Hixie> or if the page is the home page of an influential magazine editor
  357. # [07:27] <Hixie> who might review your product
  358. # [07:27] <Hixie> for deciding if it's an important semantic... it's a harder call
  359. # [07:27] <Lachy> yeah, well there are plenty of major web development related sites that use those elements
  360. # [07:28] <Hixie> in practice, i've been adding elements from HTML4, and mostly dropping attributes
  361. # [07:28] <Hixie> might need to revisit some, we'll see
  362. # [07:28] <Hixie> <samp> is used very rarely, iirc
  363. # [07:28] <Lachy> well, even if people only use it to get the monospace font for code samples, that's better than <font family="">
  364. # [07:28] <Hixie> might be able to drop that one without too much issue
  365. # [07:28] <Lachy> face="", even
  366. # [07:28] <Hixie> yeah
  367. # [07:28] <Hixie> well
  368. # [07:28] <Hixie> we could readd <Tt>
  369. # [07:28] <Hixie> if that was the concern
  370. # [07:29] <Hixie> but *shrug*
  371. # [07:29] <Hixie> i'm inclined to just keep the four of them as is
  372. # [07:29] <Lachy> given the objections to <b> and <i> so far, I don't think redefining <tt> would go down well
  373. # [07:29] <Hixie> i need to do the study for headers="" that i described in www-html
  374. # [07:29] <Hixie> that too
  375. # [07:41] * Quits: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  376. # [07:47] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  377. # [08:02] * Joins: jruderman (n=jruderma@c-67-169-183-228.hsd1.ca.comcast.net)
  378. # [08:10] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("This computer has gone to sleep")
  379. # [08:12] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  380. # [08:18] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  381. # [08:38] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  382. # [08:39] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  383. # [08:49] * Joins: Charl (n=charlvn@c1-109-15.wblv.isadsl.co.za)
  384. # [09:07] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  385. # [09:16] * Quits: Charl (n=charlvn@c1-109-15.wblv.isadsl.co.za) ("Leaving")
  386. # [09:29] * Joins: mikeday (n=mikeday@CPE-60-224-50-129.vic.bigpond.net.au)
  387. # [09:37] <mikeday> the HTML5 spec instructs user agents to treat ISO-8859-1 as Windows-1252
  388. # [09:37] <mikeday> should they also treat US-ASCII as Windows-1252?
  389. # [09:38] <mikeday> I mean, it makes sense to do so...
  390. # [09:38] <othermaciej> possibly - should probably test in Win IE, and see if any pages report themselves as US-ASCII
  391. # [09:40] <mikeday> just take a Windows-1252 page with a bunch of 8-bit characters and mislabel the encoding I suppose
  392. # [09:40] <Hixie> iirc IE treats US-ASCII as US-ASCII
  393. # [09:40] <Hixie> it strips the 8th bit
  394. # [09:40] <Hixie> might be a security whole, in fact
  395. # [09:40] <Hixie> hole even
  396. # [09:40] <mikeday> hi Hixie
  397. # [09:40] * Joins: wakaba (n=w@118.166.210.220.dy.bbexcite.jp)
  398. # [09:41] <Hixie> hi
  399. # [09:41] <mikeday> so it's just ISO-8859-1 that's ignored then
  400. # [09:41] <othermaciej> strips the 8th bit?
  401. # [09:41] <othermaciej> wow
  402. # [09:41] <othermaciej> that's definitely dangerous compared to skipping characters with the high bit set
  403. # [09:41] <Hixie> you'd have to test it to see
  404. # [09:41] <Hixie> i may be wrong
  405. # [09:41] <mikeday> or turning characters with high bit set to U+FFFD, as HTML5 would require I guess
  406. # [09:41] <Hixie> or they may have fixed it
  407. # [09:43] <mikeday> hmm, looks like it's stripping the 8th bit here
  408. # [09:43] <mikeday> (in IE 6)
  409. # [09:45] <mikeday> 0xC0 becomes 0x40
  410. # [09:45] <mikeday> Ŕ -> @
  411. # [09:45] <mikeday> will this behaviour go in the spec too? :)
  412. # [09:53] <Hixie> no
  413. # [09:53] <Hixie> it's a securty nightmare
  414. # [09:53] <Hixie> i wonder how easy it would be to trick IE into thinking the harset was US-ASCII
  415. # [09:54] <mikeday> eg. write <script> and such but with the high bit set?
  416. # [09:54] * Joins: peepo (n=Jay@host81-132-186-246.range81-132.btcentralplus.com)
  417. # [09:55] <Hixie> yah
  418. # [09:55] <mikeday> just to be absolutely clear, I assume that the high bit -> U+FFFD applies when in US-ASCII, right?
  419. # [09:55] <Lachy> I don't understand why Jukka doesn't think your sample from Google's cache isn't a valid sample
  420. # [09:55] <Hixie> mikeday: i dunno, does US-ASCII have a spec that says how to map 8-bit characters to unicode?
  421. # [09:56] <othermaciej> google doesn't give enough weighting to sites that are authored with correct semantics
  422. # [09:56] <mikeday> hmm, I don't think the spec for US-ASCII (which spec, anyway?) says anything about bytes > 127
  423. # [09:56] <othermaciej> google should probably just refuse to show invalid sites when you do a search query
  424. # [09:57] <Lachy> othermaciej, isn't that a good thing, since it's representative of the whole web, not just the proportion of semantically correct pages
  425. # [09:57] <Hixie> Lachy: he's right. if you don't work from the assumption that i'm not trying to pull a fast one, you have no reason to trust my data.
  426. # [09:57] <mikeday> heh, that would certainly save google indexing space :)
  427. # [09:57] <Hixie> othermaciej: actually, it's probably the opposite :-)
  428. # [09:57] <Hixie> yeah seriously, we could save so much disk space if we only had to store the four valid pages
  429. # [09:57] * Quits: wakaba_ (n=w@118.166.210.220.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
  430. # [09:58] <Hixie> Lachy: see also mail i just sent
  431. # [09:59] * Quits: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  432. # [09:59] <othermaciej> personally I'd prefer an experiment that was reproducible, even if it was based on a smaller sample set
  433. # [09:59] <othermaciej> but I also think Hixie has no motive to falsify the data and the odds of error are fairly low
  434. # [10:00] <mikeday> (if I may satisfy my morbid curiousity, is this a publically archived argument that you're discussing?)
  435. # [10:01] <Lachy> see www-html
  436. # [10:02] <Hixie> othermaciej: yeah, i'd really really love to have people reproduce this
  437. # [10:02] <Hixie> othermaciej: don't really know how to do it though
  438. # [10:03] <Hixie> othermaciej: where "it" is "find a representative sample without using google's resources"
  439. # [10:03] <othermaciej> still, the claim to being scientific would be better
  440. # [10:03] <Hixie> well, i've never made a claim to being scientific
  441. # [10:03] <Hixie> in fact quite the opposite :-)
  442. # [10:03] <othermaciej> well, it would be possible to make a claim to being scientific
  443. # [10:03] <Lachy> unfortunately, few people have the recources available to reproduce a study of billions of documents, though we could do it on a smaller scale of thousands of pages
  444. # [10:04] <othermaciej> I wonder if any site has a readily publicly available representative corpus of web documents
  445. # [10:04] <Hixie> i'd love e.g. yahoo or microsoft to do something like this
  446. # [10:04] <Hixie> othermaciej: yeah the problem is making that sample is Really Hard (tm)
  447. # [10:05] <Hixie> othermaciej: because any crawling strategy is inherently biased towards front pages until you have several million pages
  448. # [10:06] <othermaciej> bias towards front pages is not the worst thing but I guess it would bury a lot of important data
  449. # [10:07] <Lachy> bias toward front pages is probably quite a good thing, since it lowers the chance of a relatively unimportant set of pages skewing the results
  450. # [10:08] <Hixie> bias towards front pages is really, really visible in results
  451. # [10:08] <Hixie> it makes a huge difference
  452. # [10:08] <Hixie> front pages have massively different characteristics
  453. # [10:08] <Hixie> far more than i expected
  454. # [10:08] <Lachy> oh, I think I misinterpreted what you meant by front pages. do you mean like the home pages of sites?
  455. # [10:09] <Hixie> yeah
  456. # [10:09] <Hixie> what did you mean?
  457. # [10:10] <Lachy> from your email, you said "biased by what Google has algorithmically established would be most "interesting" to its potential users". I just assumed you were also referring to pages with higher page rank
  458. # [10:14] <Hixie> aah
  459. # [10:16] <othermaciej> whoah
  460. # [10:16] <othermaciej> I can't believe someone things the fact that some accessibility software ignores headers="" in favor of heuristics is an argument *for* having headers="" in the spec
  461. # [10:18] <Hixie> yeah that didn't really make sense to me either
  462. # [10:18] * Joins: ROBOd (n=robod@86.34.246.154)
  463. # [10:18] <Hixie> but there were some good points made on that threatd so i saved thosee-mails for when i look at tables next
  464. # [10:19] * Joins: zcorpan_ (n=zcorpan@84-216-41-128.sprayadsl.telenor.se)
  465. # [10:19] * Quits: jruderman (n=jruderma@c-67-169-183-228.hsd1.ca.comcast.net)
  466. # [10:22] <mikeday> hmm, did you just say you're looking at tables? will that include layout issues, or just element usage/semantics?
  467. # [10:22] <othermaciej> I'm glad I am not on www-html
  468. # [10:23] <othermaciej> I don't think I could remain reasonably polite
  469. # [10:23] <Hixie> mikeday: i will in due course look at both. right now i'm doing canvas.
  470. # [10:25] * Quits: peepo (n=Jay@host81-132-186-246.range81-132.btcentralplus.com) ("later")
  471. # [10:26] <mikeday> I must say I rather like the <code> tag
  472. # [10:26] <mikeday> even if sometimes it only really means "make this monospace"
  473. # [10:27] <Hixie> wow, jukka is, ah, rude
  474. # [10:28] <mikeday> is the whole argument over whether "sample" means "random sample" ?
  475. # [10:28] <Hixie> no idea
  476. # [10:28] <Hixie> i don't know what he's talking about
  477. # [10:28] <Hixie> since the data in question is indeed a statistical sample
  478. # [10:29] <mikeday> maybe easier to say "subset" of the web
  479. # [10:29] <mikeday> as that's unarguable
  480. # [10:29] <Hixie> depending on how you define the sampling frame, it's either a 100% sample of the sampling frame, or a biased sample of the sampling frame, biasing towards "interesting" pages
  481. # [10:29] <Hixie> yeah
  482. # [10:30] <Hixie> i don't think he's really interested in the actual data
  483. # [10:30] <Hixie> looks like he just wants to argue
  484. # [10:30] <Hixie> you know, i think what's happened is that a lot of people have been saying for years that html5 is not legit, that it's a stupid project, that html is dead
  485. # [10:31] <Hixie> and now that the w3c has taken html5 as the base for the next version of html, and said html is indeed alive and well, they feel somewhat cheated
  486. # [10:31] <mikeday> HTML: I'm not dead yet!
  487. # [10:31] * Joins: hendry (n=hendry@91.84.62.62)
  488. # [10:32] * zcorpan_ is now known as HTML
  489. # [10:32] * HTML is alive
  490. # [10:32] <mikeday> if Google follows the information destruction policy as described in The Onion
  491. # [10:32] <Lachy> HTML has been intensive care for a few years, though it's starting to stabalise now
  492. # [10:32] * HTML is now known as zcorpan
  493. # [10:32] <mikeday> then it will only be a matter of time before your sample is a 100% sample :)
  494. # [10:33] <mikeday> http://www.theonion.com/content/node/40076
  495. # [10:36] <Lachy> lol :-)
  496. # [10:38] <mikeday> if there is "paving the cowpaths" for standardising common idioms
  497. # [10:38] <mikeday> how to say "getting rid of stuff no one uses"?
  498. # [10:39] <Lachy> if google purge can be extended to purge all non-conforming web pages, that would solve all out backwards compatibility issues
  499. # [10:39] <othermaciej> "Don't be evil, unless it's necessary for the greater good."
  500. # [10:39] <mikeday> Lachy, that's called "pulling the plug on the entire web"
  501. # [10:39] <mikeday> (except for the four valid pages mentioned earlier)
  502. # [10:40] <Lachy> yeah, well, there are plans to replace the entire web. There was an article about it, mentioned on slashdot
  503. # [10:42] <othermaciej> we weill rewrite the web in valid xhtml2
  504. # [10:43] <mikeday> might as well fix HTTP and come up with a better URL mechanism while you're at it
  505. # [10:44] <zcorpan> it boiled down to replacing the earth last time this came up... :)
  506. # [10:44] * Joins: BenWard (i=BenWard@nat/yahoo/x-5e9f9c5c7f70998a)
  507. # [10:44] <mikeday> why stop there? some of the laws of physics could be improved :)
  508. # [10:44] <zcorpan> oh indeed
  509. # [10:44] <mikeday> tweak electromagnetism to reduce the latency of my connection, thanks :)
  510. # [10:45] <zcorpan> lol
  511. # [10:45] <Lachy> the earth is already dead, we're all moving to that new planet 20 light years away
  512. # [10:46] <zcorpan> we need a planet that is flat
  513. # [10:46] <mikeday> hmm, by the time we get there, everyone will have reached agreement on the semantics of elements in HTML5 (maybe)
  514. # [10:46] <Lachy> you can't go down hill skiing if the whole planet is flat
  515. # [10:46] <Lachy> we need one on a slope
  516. # [10:47] <mikeday> a world on the inside of a giant bowl would be handy
  517. # [10:47] <mikeday> then you could have your skiing,
  518. # [10:47] <mikeday> and we could use microwave links from any point to any other point on the bowl
  519. # [10:48] <Lachy> no, not a bowl, we'll all be eaten the the flying spagetti monster
  520. # [10:48] <mikeday> :)
  521. # [10:48] <othermaciej> whoah, what do "char" and "charoff" attributes on <td> mean?
  522. # [10:49] <othermaciej> mikeday: we will use a mix of XRIs, IRIs and CURIEs, and HTTP-NG
  523. # [10:49] <mikeday> char is for alignment, right?
  524. # [10:49] <zcorpan> alignment of a column, yes
  525. # [10:50] <zcorpan> does <td char> mean that you align the cell at a char against itself?
  526. # [10:50] <Lachy> they're for aligning cells based on teh position of a character, so for example you could align all the decimal points
  527. # [10:50] <mikeday> why were IRIs necessary at all, why not URI v2 or URI++ or something?
  528. # [10:51] <zcorpan> URL5
  529. # [10:51] <mikeday> right!
  530. # [10:51] <mikeday> someone totally needs to write that spec
  531. # [10:52] <mikeday> and by someone I mean Hixie
  532. # [10:52] <Lachy> what's wrong with IRIs, other than the name?
  533. # [10:52] <mikeday> :)
  534. # [10:52] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  535. # [10:52] <mikeday> Lachy, the name is bad enough, and the fact that they're 10 years too late
  536. # [10:52] <mikeday> aside from that, no objections :)
  537. # [10:53] <Hixie> the main problem with IRIs is that they're not backwards compatible with pages that use non-ascii characters and that are not encoded as UTF-8
  538. # [10:53] <Hixie> but apart from not being compatible with most of the wb, they're fine
  539. # [10:53] <Lachy> while we're at it, Hixie should write CSS5, XML5 (take it over from anne), JavaScript5, FooML5, etc.
  540. # [10:53] <Hixie> let's do HTML5 first
  541. # [10:54] <Hixie> maybe i can then use my experience with web standards to start UN5
  542. # [10:54] <mikeday> heh
  543. # [10:54] <mikeday> that'd be a riot
  544. # [10:54] <mikeday> "no one obeys these laws, so let's drop 'em"
  545. # [10:55] <mikeday> (regarding, say, file sharing)
  546. # [10:55] <othermaciej> wow, a lot of pages use <ruby>
  547. # [10:56] <Philip`> More than <perl>?
  548. # [10:56] <zcorpan> <sam> <ruby>
  549. # [10:56] <othermaciej> no, the tag
  550. # [10:56] * othermaciej rolls his eyes in exhasperation
  551. # [10:56] <Hixie> hah
  552. # [10:56] <Hixie> and yeah
  553. # [10:57] <mikeday> is Ruby defined in an HTML specification, or only in XHTML?
  554. # [10:57] <zcorpan> XHTML
  555. # [11:02] <Hixie> html5 will define it in due course
  556. # [11:02] <Hixie> in a simplified version
  557. # [11:02] <mikeday> by the way, line 33057 of the HTML5 spec has an unescaped <, which appears to be a parse error
  558. # [11:02] <Hixie> with error handling
  559. # [11:02] <Hixie> mikeday: it'll get fixed in due course. don't worry about typos and stuff :-)
  560. # [11:03] <Hixie> bed time
  561. # [11:03] <Hixie> nn
  562. # [11:04] <othermaciej> I think XHTML incorporates it by reference from a separate spec
  563. # [11:05] <othermaciej> I have to learn more about why some people think modules and profiles and such are so cool
  564. # [11:05] <othermaciej> and namespaces
  565. # [11:05] <othermaciej> I have a hard time grasping how having many dialects and many languages could improve communication
  566. # [11:06] * zcorpan doesn't get it either
  567. # [11:07] <othermaciej> I think it has to do with the desire to have everything be defined
  568. # [11:08] <othermaciej> since not everything can practically be predefined, you need a way to make your own dictionaries
  569. # [11:08] <zcorpan> doesn't class="" allow for that?
  570. # [11:11] <othermaciej> no, because it just lets you *use* things, without linking to a definition of them
  571. # [11:11] <othermaciej> thus profile="", or role="" with RDFa
  572. # [11:13] <zcorpan> ah, right. because the UA magically knows about the semantics if you link to a definition
  573. # [11:13] * zcorpan has heard the same thing about shemas
  574. # [11:13] * Joins: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  575. # [11:14] <zcorpan> "browsers can't know what a custom attribute means unless it's defined in the DTD"
  576. # [11:15] <Lachy> would it be possible to define a simplified version of role="" (or equivalent) without all the RDFa and namespace stuff, which could be used just for predefined values, leaving class for author defined values
  577. # [11:15] <Lachy> I am assuming that we can actually get clear use cases from its advocates
  578. # [11:17] <othermaciej> a non-extensible role="" doesn't seem very useful
  579. # [11:18] <Lachy> it's just as useful in reality as one that's extensible using RDFa
  580. # [11:18] <Lachy> we could just leave it up to a microformat-like community to define the extensions for it
  581. # [11:19] <mikeday> darn, Hixie's already gone
  582. # [11:19] <mikeday> Hixie, if you happen to read this, consider making support for UTF-32 optional in HTML5! Thank you.
  583. # [11:19] <zcorpan> mikeday: why?
  584. # [11:20] <mikeday> because it's annoying, and I don't see why user agents should be compelled to implement support for it.
  585. # [11:20] <mikeday> does anyone regularly publish web content in UTF-32?
  586. # [11:21] <zcorpan> is utf-32 currently required?
  587. # [11:22] <Lachy> I don't believe it's required
  588. # [11:22] <Lachy> it's not required for XML either, so it wouldn't make sense to require it for HTML5
  589. # [11:22] <mikeday> maybe not required
  590. # [11:22] <mikeday> but encoding detection says that FF FE 00 00
  591. # [11:22] <mikeday> must be treated as being UTF-32 encoding
  592. # [11:22] <mikeday> rather than UTF-16LE followed by a null
  593. # [11:22] <othermaciej> implementing UTF-32 is not hard
  594. # [11:23] <Lachy> it needs to be included in the detection algorithm, but if a UA doesn't support it, it'll obviously fail
  595. # [11:23] <mikeday> actually, what is the procedure for unsupported encodings, fallback to Windows-1252 or similar?
  596. # [11:24] <mikeday> ah, "Otherwise, use an implementation-defined or user-specified default character encoding."
  597. # [11:25] <zcorpan> that's if it can't find an encoding declaration
  598. # [11:25] <mikeday> so if a BOM is found, the meta charset attribute won't be checked
  599. # [11:25] <Lachy> you can't fallback to a different encoding and still expect to get sane results, especially for unsupported UTF-32
  600. # [11:25] <zcorpan> mikeday: yes
  601. # [11:25] <mikeday> so be careful saving pages in Notepad UTF-8 mode, basically
  602. # [11:25] <Lachy> I suppose, if you get <meta charset="bogus">, you'd have to fallback
  603. # [11:25] <mikeday> as it will screw up Windows-1252 pages
  604. # [11:26] <Lachy> mikeday, how would that screw win1252 pages? They would just be treated as UTF-8, regardless of what the meta says
  605. # [11:26] <Lachy> they'd be non-conforming, though, but they'd work
  606. # [11:27] <Lachy> unless the encoding is declared in the HTTP headers as Win-1252
  607. # [11:27] <mikeday> hmm, wouldn't it garble some text?
  608. # [11:28] <Lachy> if you saved it as UTF-8 using notepad, which will add the BOM, the whole file will be encoded as UTF-8, so that's not a problem
  609. # [11:28] <mikeday> right :)
  610. # [11:28] <mikeday> hmm, I think I've found a UTF-32 BOM related bug in html5lib
  611. # [11:29] <mikeday> it checks for the UTF-16 BOM before checking for the UTF-32 BOM
  612. # [11:29] <mikeday> which means FF FE will always match UTF-16, and UTF-32 will never be returned
  613. # [11:29] <mikeday> which is why I don't like UTF-32 autodetection.
  614. # [11:30] * Joins: ROBOd2 (n=robod@86.34.246.154)
  615. # [11:30] <zcorpan> mikeday: would you like the sniffing algorithm to not look for UTF-32, and forbid UAs to support UTF-32?
  616. # [11:31] <mikeday> zcorpan, it certainly wouldn't bother me if that was the policy
  617. # [11:31] <mikeday> does anyone use UTF-32, ever?
  618. # [11:31] <zcorpan> dunno
  619. # [11:31] * zcorpan wouldn't mind either
  620. # [11:31] <mikeday> I've never seen it except in test suites
  621. # [11:32] <mikeday> expat doesn't support it
  622. # [11:32] <mikeday> so it's not widely used in the XML world
  623. # [11:32] <mikeday> it's horrendously inefficient, so it doesn't make sense to use it on the web
  624. # [11:32] <zcorpan> indeed
  625. # [11:32] <mikeday> it only really exists for logical completeness,
  626. # [11:32] <mikeday> as an example of how UNICODE could potentially be encoded
  627. # [11:32] <mikeday> and there's four different potential endianesses for it, which is just stupid
  628. # [11:33] <mikeday> (although HTML5 only mentions two)
  629. # [11:33] <zcorpan> mail the list
  630. # [11:33] <mikeday> alrighty
  631. # [11:34] <mikeday> which list? :)
  632. # [11:34] <zcorpan> whatwg@whatwg.org
  633. # [11:35] * othermaciej is now known as om_sleep
  634. # [11:37] * Joins: maikmerten (n=maikmert@La751.l.pppool.de)
  635. # [11:39] <mikeday> sent
  636. # [11:39] <mikeday> and the crusade to abolish UTF-32 marches on.
  637. # [11:39] * mikeday is now known as mikeday|away
  638. # [11:41] * Quits: ROBOd (n=robod@86.34.246.154) (Read error: 110 (Connection timed out))
  639. # [11:41] * Quits: Lachy (n=Lachlan@203-217-95-91.dyn.iinet.net.au) (Read error: 54 (Connection reset by peer))
  640. # [11:53] * Joins: Lachy (n=Lachlan@203-217-95-91.dyn.iinet.net.au)
  641. # [11:55] <Dashiva> Poor utf-32, what did it ever do to you?
  642. # [11:58] <zcorpan> cause bugs in software? :)
  643. # [11:58] <zcorpan> waste people's time?
  644. # [12:18] <Dashiva> But complaining about it causes +1 posts on whatwg :)
  645. # [12:32] * Quits: zcorpan (n=zcorpan@84-216-41-128.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  646. # [12:33] * Joins: zcorpan (n=zcorpan@84-216-41-128.sprayadsl.telenor.se)
  647. # [12:46] * mikeday|away is now known as mikeday
  648. # [12:48] <mikeday> yay, +1 posts
  649. # [12:48] <mikeday> probably time someone specified UTF-64, for people who like even more null bytes in their text
  650. # [12:49] <Lachy> that'd be awesome! cause 64 bit processing is much faster than 32 ;-)
  651. # [12:50] <mikeday> twice the bits :)
  652. # [12:51] <mikeday> <cue Nintendo fan enthusiasm>
  653. # [12:52] * zcorpan likes nintendo 8-bit
  654. # [12:52] <Lachy> UTF-128 would be more secure
  655. # [12:53] <mikeday> if UNICODE was a 128 bit character set,
  656. # [12:53] <mikeday> you could represent each character as a bitmap glyph image
  657. # [12:53] <mikeday> no need for fonts :)
  658. # [12:54] <zcorpan> SVG is the replacement of unicode!
  659. # [12:54] <zcorpan> brillant
  660. # [12:54] <Lachy> SVG is also the replacemetn for TTF
  661. # [12:54] <mikeday> of course, then you need a character encoding to encode your SVG in... ASCII? :)
  662. # [12:55] <Lachy> ASCII 5!
  663. # [12:55] <mikeday> more work for Hixie
  664. # [12:55] <mikeday> better begin at the beginning, and define binary5 first
  665. # [12:56] <mikeday> check with Google and see if people use 1 more or 0
  666. # [12:56] <Lachy> yeah, we should ditch the 8th bit while we're at it. We don't need octets to encode 7 bit encodings
  667. # [12:56] <zcorpan> shouldn't ASCII5 be 5-bit?
  668. # [12:57] <Lachy> we could ditch 28 of the 31 control characters
  669. # [12:57] <zcorpan> and things like ~
  670. # [12:57] <zcorpan> that aren't used in english anyway
  671. # [12:58] <mikeday> dropping ~ might make it difficult to find your home directory
  672. # [12:58] <mikeday> drop uppercase letters would be better
  673. # [12:59] <zcorpan> yeah
  674. # [12:59] <mikeday> you could always use some kind of stateful caps character if necessary
  675. # [12:59] <Lachy> so we're left with LF, TAB, Space, A-Za-z0-9 and a few symbols
  676. # [12:59] <Dashiva> No bell?
  677. # [12:59] <mikeday> have we just reinvented baudot codes? :)
  678. # [12:59] <mikeday> http://en.wikipedia.org/wiki/Baudot
  679. # [12:59] <Lachy> we could redefine NUL to beep whenever its used
  680. # [13:08] <mikeday> yay, I have written a function that checks for a BOM.
  681. # [13:08] <mikeday> Truly, it's all downhill from here.
  682. # [13:09] * Quits: wakaba (n=w@118.166.210.220.dy.bbexcite.jp) (heinlein.freenode.net irc.freenode.net)
  683. # [13:09] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (heinlein.freenode.net irc.freenode.net)
  684. # [13:09] * Quits: laug (n=laug@poy.chewa.net) (heinlein.freenode.net irc.freenode.net)
  685. # [13:09] * Quits: didymos (i=jho@rapwap.razor.dk) (heinlein.freenode.net irc.freenode.net)
  686. # [13:09] * Quits: bewest (n=ben@httpcraft/bewest) (heinlein.freenode.net irc.freenode.net)
  687. # [13:09] * Quits: deltab (n=deltab@82-46-154-93.cable.ubr02.smal.blueyonder.co.uk) (heinlein.freenode.net irc.freenode.net)
  688. # [13:11] * Joins: wakaba (n=w@118.166.210.220.dy.bbexcite.jp)
  689. # [13:11] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  690. # [13:11] * Joins: bewest (n=ben@httpcraft/bewest)
  691. # [13:11] * Joins: didymos (i=jho@rapwap.razor.dk)
  692. # [13:11] * Joins: laug (n=laug@poy.chewa.net)
  693. # [13:11] * Joins: deltab (n=deltab@82-46-154-93.cable.ubr02.smal.blueyonder.co.uk)
  694. # [13:29] * Joins: bzed (n=bzed@dslb-084-059-127-008.pools.arcor-ip.net)
  695. # [13:39] <mikeday> hmm, C still has no max function
  696. # [13:40] <mikeday> I guess so that language tutorials can still define it as a macro
  697. # [13:41] * Quits: nickshanks (n=nicholas@home.nickshanks.com)
  698. # [13:56] <zcorpan> http://tom.opiumfield.com/blog/2007/05/15#When:08:46:09
  699. # [13:57] * Joins: jdandrea (n=jdandrea@ool-44c0a58f.dyn.optonline.net)
  700. # [13:58] <Lachy> I like how he disputes my claim about it being useless in practice, by pointing to a spec that isn't really used in practice
  701. # [13:58] <zcorpan> :)
  702. # [14:00] <Lachy> I think Ruby's postulate applies to the problem with the profile attribute: "The accuracy of metadata is inversely proportional to the square of the distance between the data and the metadata."
  703. # [14:00] <Lachy> Sticking the profile in the <head> is too far away from the actual data in the body
  704. # [14:09] * Quits: mikeday (n=mikeday@CPE-60-224-50-129.vic.bigpond.net.au) ("-")
  705. # [14:10] <zcorpan> Levels of HTML knowledge
  706. # [14:10] <zcorpan> 1. <i> is presentational! <em> is more semantic. let's replace <i>s with <em>s.
  707. # [14:10] <zcorpan> 2. <em> represents emphasis! not italics. don't use <em> when you mean italics.
  708. # [14:10] <zcorpan> 3. <i> and <em> are sysnonyms.
  709. # [14:11] <zcorpan> s/knowledge/insight/
  710. # [14:12] <Lachy> I don't quite agree with #3
  711. # [14:12] <Lachy> <em> usually means emphasis, <i> has context sensitive semantics
  712. # [14:13] * Parts: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  713. # [14:13] <zcorpan> in practice, <em> has context sensitive semantics, too
  714. # [14:13] <Lachy> possibly, but not quite as much as i
  715. # [14:14] <zcorpan> from a markup consumer's pov, there's no benefit in treating them differently
  716. # [14:16] <Lachy> the benefit is more from an authors point of view, cause it allows you to style them differently without having to use classes
  717. # [14:16] <zcorpan> sure
  718. # [14:28] <Lachy> ha, this is awesome. http://hugeurl.com/
  719. # [14:28] <zcorpan> LOL
  720. # [14:31] <Lachy> this is so much easier to remember http://www.hugeurl.com/?YjJlNTg2ZmUzYzc5NWIwZjZhMzRiZTk2NzBkNmJiMTkmMTMmVm0wd2QyUXlVWGxWV0d4WFlUSm9WMVl3Wkc5V1ZsbDNXa2M1YWxKc1dqQlVWbHBQVjBaYWMySkVUbGhoTVVwVVZtcEdZV015U2tWVWJHaG9UV3N3ZUZacVFtRlRNazE1VTJ0V1ZXSkhhRzlVVm1oRFZWWmFkR1ZHV214U2JHdzFWa2QwYzJGc1NuUmhSemxWVmpOT00xcFZXbUZrUjA1R1pFWlNUbFpVVmtwV2JURXdZVEZrU0ZOclpHcFRSVXBZVkZWYWQxTkdVbFZTYlVacVZtdGFNRlZ0ZUZOVWJVWTJVbFJHVjFaRmIzZFdha1poVjBaT2NtSkdTbWxT
  721. # [14:31] <Lachy> TW1oWlYxZDRiMkl3TUhoWGJHUllZbFZhY2xWc1VrZFhiR3QzV2tSU1ZrMXJjRWxhU0hCSFZqSkZlVlZZWkZwV1JWcHlWVEJhVDJOc2NFaGpSbEpUVmxoQ1dsWnJXbGRoTVZWNVZXNU9hbEp0VWxsWmJGWmhZMVpzY2xkdFJteFdiVko1VmpJMWExWXdNVVZTYTFwV1lrWktSRlpxUVhoa1ZsWjFWMnhhYUdFeGNGbFhhMVpoVkRKT2RGTnJaRlJpVjNoWVZXcE9iMWRHV25STlNHUnNVakJzTkZVeWRHdGhWazVHVjJ4U1dtSkhhRlJXTVZwWFkxWktjbVJHVWxkaVJtOTNWMnhXYjJFeFdYZE5WVlpUWVRGd1dGbHJaRzlqYkZweFUydGFiRlpzV2xwWGExcHJZVWRGZUdOR2JGaGhNVnBvVmtSS1RtVkd
  722. # [14:31] <Lachy> jRWxVYldoVFRXNW9WVlpHWTNoaU1XUnpWMWhvV0dKWVVrOVZiVEUwVjBaYVdHUkhkRmRpVlhCSldWVm9UMVp0Um5KVGJXaGFUVlp3YUZwRlpFOU9iRXB5VGxaa2FWZEdSalpXYWtvd1ZURlZlRmR1U2s1V1ZscFVXV3RrVTFsV1VsWlhiVVpzWWtac00xWXlNVWRWTWtwR1RsaHdWMVl6YUhaV2FrcExVMVpHYzJGR2FHbFNia0p2Vm10U1MxUXlUWGxVYTFwaFVqSm9WRlJYTlc5V1ZtUlhWV3M1VWsxc1NucFdNalZUVkd4a1NGVnNXbFZXYkhCWVZHeGFWMlJIVWtoa1JtUnBWbGhDTmxaVVNURlVNVnAwVW01S1QxWnNTbGhVVlZwM1ZrWmFjVkp0ZEd0U2EzQXdXbFZhYTJGV1RrWlRhM1JYVFZaS1
  723. # [14:31] <Lachy> VGcEVSbHBsUm1SMVUyczFWMVpzY0ZWWFYzUnJWVEZzVjFWc1dsaGlWVnB6V1d0YWQyVkdWblJOVldSV1RXdHdWMVp0Y0dGWGJGcFhZMGRvV2xaWFVrZGFWV1JQVWpKR1IyRkhiRk5pYTBwMlZteG9kMUl5UlhoYVJXUldZbXR3YUZWdE1XOWpSbHB4VkcwNVYxWnNjRWhYVkU1dllWVXhXRlZzYUZkTlYyaDJWMVphUzFKc1RuUlBWbFpYVFRGS05sWkhkR0ZXYlZaWVZXdG9hMUp0VWs5V2FrWkxVMnhrVjFadFJsWk5WbXcxVld4b2MxWnNXa1pUYkdoWFlXczFkbGxWV21GalZrcHpXa1pvVjJKclNrbFdWbVEwV1ZaWmVGTnJXbE5XUlZVNQ==
  724. # [14:31] <Lachy> dang, it's too long for IRC
  725. # [14:33] <zcorpan> try to feed it through tinyurl
  726. # [14:33] <Lachy> lol
  727. # [14:34] * Quits: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) (Read error: 110 (Connection timed out))
  728. # [14:34] <zcorpan> http://tinyurl.com/39wc8s
  729. # [14:34] <zcorpan> success!
  730. # [14:34] <Lachy> hey, if we point hugeurl at tinyuri, and then point tinyurl to that generated url, we'd get a loop!
  731. # [14:35] <Lachy> oh, that wouldn't work
  732. # [14:35] <Lachy> we'd need to know both URLs before we generate to get a loop
  733. # [14:36] <Lachy> damn! laws of physics get in the way every time :-)
  734. # [14:40] * Joins: jdandrea_ (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  735. # [14:42] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  736. # [14:50] <Dashiva> Lachy: I'm sure you can find a collision somehow
  737. # [14:56] * Joins: annevk (n=annevk@194.206.50.135)
  738. # [14:57] <annevk> fillStyle = "currentColor" is interesting
  739. # [14:57] * Quits: jdandrea (n=jdandrea@ool-44c0a58f.dyn.optonline.net) (Read error: 110 (Connection timed out))
  740. # [15:42] * krijnh is excited
  741. # [15:42] <Lachy> krijnh, excited about what?
  742. # [15:42] <krijnh> Lachy: about meeting annevk next week ;p
  743. # [15:43] <Lachy> ok
  744. # [15:43] * Joins: jcgregorio (i=chatzill@nat/ibm/x-912ab8e71a08bd6b)
  745. # [15:44] <annevk> krijnh, going to Oslo?!
  746. # [15:44] <krijnh> annevk: nah, staying in NL
  747. # [15:44] <krijnh> I'm probably misinformed :)
  748. # [15:45] <annevk> I suppose
  749. # [15:48] <krijnh> Wrt the plans ppk has
  750. # [15:48] <annevk> ah, ok
  751. # [15:48] <annevk> yeah, I hope to attend at some point
  752. # [15:48] <annevk> but for now I'm stuck in other countries
  753. # [15:48] <annevk> currently France
  754. # [15:49] <krijnh> Not too bad I think :)
  755. # [15:50] <annevk> some clouds
  756. # [15:50] <annevk> good food though
  757. # [15:50] * annevk had some italian
  758. # [15:50] <krijnh> Pain du stok
  759. # [16:06] * Joins: SpookyET (i=user@75.138.70.34)
  760. # [16:17] * Quits: SpookyET (i=user@75.138.70.34) (Remote closed the connection)
  761. # [16:20] * Joins: SpookyET (i=user@75.138.70.34)
  762. # [16:24] * Quits: hendry (n=hendry@91.84.62.62) (Read error: 113 (No route to host))
  763. # [16:33] * Quits: annevk (n=annevk@194.206.50.135) (Read error: 110 (Connection timed out))
  764. # [16:37] * Joins: hendry (n=hendry@91.84.62.62)
  765. # [16:42] * Joins: billmason (n=billmaso@ip156.unival.com)
  766. # [16:45] * Joins: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  767. # [16:51] * Joins: syp_ (n=syp@photpc17.epfl.ch)
  768. # [16:51] * Quits: syp (n=syp@photpc17.epfl.ch) (Read error: 104 (Connection reset by peer))
  769. # [16:55] * Quits: syp_ (n=syp@photpc17.epfl.ch) (Read error: 104 (Connection reset by peer))
  770. # [16:56] * Joins: syp (n=syp@photpc17.epfl.ch)
  771. # [16:58] * Quits: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  772. # [17:01] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  773. # [17:08] * Joins: syp_ (n=syp@photpc17.epfl.ch)
  774. # [17:08] * Quits: syp (n=syp@photpc17.epfl.ch) (Read error: 104 (Connection reset by peer))
  775. # [17:10] <csarven> http://arapehlivanian.com/2007/05/15/design-by-committee
  776. # [17:29] * Quits: maikmerten (n=maikmert@La751.l.pppool.de) (Read error: 104 (Connection reset by peer))
  777. # [17:34] * Joins: maikmerten (n=maikmert@La751.l.pppool.de)
  778. # [17:35] * Joins: jdandrea (n=jdandrea@ool-44c0a58f.dyn.optonline.net)
  779. # [17:37] * Joins: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net)
  780. # [17:44] * Quits: jdandrea_ (n=jdandrea@ool-44c0a1fe.dyn.optonline.net) (Read error: 60 (Operation timed out))
  781. # [17:46] <krijnh> What's up with all these 'Google' referrers on http://krijnhoetmer.nl/irc-logs/ ? :s
  782. # [18:03] <Philip`> zcorpan: I just noticed http://dean.edwards.name/weblog/2007/03/google-it/ had a note about mime-types in Google Code, which sounds like it could be used for serving author-view-of-html5.css directly
  783. # [18:06] <zcorpan> Philip`: cool
  784. # [18:06] <Lachy> heh, I found out where the "Google (Tina Holmboe)" referrers came from. Tina seems a little annoyed http://lists.w3.org/Archives/Public/www-html/2007May/0491.html (see the footnote)
  785. # [18:08] <Dashiva> Calling other people opponents isn't very constructive in a consensus-based activity
  786. # [18:11] <Lachy> I'm getting tired of discussing her anyway, she seems to be trolling a little
  787. # [18:22] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  788. # [18:22] <krijnh> Lachy: I mean the Google referrers without search terms
  789. # [18:23] * Joins: aroben (n=adamrobe@17.203.15.208)
  790. # [18:25] <Philip`> Maybe the front page of Google has a hidden link to your site?
  791. # [18:25] <Lachy> krijnh, I realised that
  792. # [18:26] <krijnh> Philip`: Yeah, perhaps..
  793. # [18:43] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  794. # [18:44] * Joins: KevinMarks (i=KevinMar@nat/google/x-967bf60b97f7ac2f)
  795. # [18:44] * Quits: BenWard (i=BenWard@nat/yahoo/x-5e9f9c5c7f70998a) ("Fades out again…")
  796. # [18:45] * Joins: webben (i=benh@nat/yahoo/x-0f1de7593280534a)
  797. # [18:58] * Joins: tantek (n=tantek@corp.technorati.com)
  798. # [19:20] * Quits: maikmerten (n=maikmert@La751.l.pppool.de) (Remote closed the connection)
  799. # [19:24] * Joins: maikmerten (n=maikmert@La751.l.pppool.de)
  800. # [19:26] * Quits: maikmerten (n=maikmert@La751.l.pppool.de) (Remote closed the connection)
  801. # [19:29] * Quits: webben (i=benh@nat/yahoo/x-0f1de7593280534a) (Client Quit)
  802. # [19:29] * Joins: hendry_ (n=hendry@91.84.62.62)
  803. # [19:32] * Quits: hendry (n=hendry@91.84.62.62) (Read error: 60 (Operation timed out))
  804. # [19:35] * Joins: maikmerten (n=maikmert@La751.l.pppool.de)
  805. # [19:41] * Quits: KevinMarks (i=KevinMar@nat/google/x-967bf60b97f7ac2f) ("The computer fell asleep")
  806. # [19:46] * Quits: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  807. # [19:54] * Joins: Lachy_ (n=Lachlan@210-84-45-98.dyn.iinet.net.au)
  808. # [19:56] * moeffju is now known as moeffju[away]
  809. # [19:57] * Quits: Lachy (n=Lachlan@203-217-95-91.dyn.iinet.net.au) (Read error: 60 (Operation timed out))
  810. # [20:03] * Joins: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  811. # [20:07] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  812. # [20:10] * Quits: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) ("Ik ga weg")
  813. # [20:10] * Joins: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  814. # [20:18] * Joins: kingryan (n=kingryan@corp.technorati.com)
  815. # [20:25] * Joins: jruderman (n=jruderma@c-67-169-183-228.hsd1.ca.comcast.net)
  816. # [20:27] * gsnedders installs Opera Mini on his phone
  817. # [20:34] <gsnedders> ergh. network won't allow anything apart from their own shitty browser :\
  818. # [20:36] * Joins: KevinMarks (i=KevinMar@nat/google/x-f0ddca996f88902e)
  819. # [20:37] <gsnedders> or I've been an idiot.
  820. # [20:37] <gsnedders> (more likely answer)
  821. # [20:37] <zcorpan> http://me.mywebsight.ws/2007/05/15/xhtml-2-and-html-5-who-will-win/
  822. # [20:38] <gsnedders> zcorpan: Ignorance is bliss.
  823. # [20:39] <zcorpan> yeah well
  824. # [20:40] * om_sleep is now known as othermaciej
  825. # [20:45] * Quits: KevinMarks (i=KevinMar@nat/google/x-f0ddca996f88902e) ("The computer fell asleep")
  826. # [20:50] * Quits: jcgregorio (i=chatzill@nat/ibm/x-912ab8e71a08bd6b) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/0000000000]")
  827. # [21:10] * Quits: SpookyET (i=user@75.138.70.34) ("Client Exiting")
  828. # [21:17] <Dashiva> "the browser vendors (lazy idiots, get some real work done, espeacily you morons from redmond)"
  829. # [21:21] <othermaciej> telling people what to do is real work, doing it is lazy
  830. # [21:31] <Dashiva> And in one of the articles linked, about xhtml2, "The iframe element, which has always caused problems for users of assistive technologies, will not be missed."
  831. # [21:32] * Dashiva sighs
  832. # [21:32] <bewest> othermaciej: this is just more evidence that people blame browser vendors :-)
  833. # [21:32] <bewest> othermaciej: (there was some dispute of that claim, wasn't there)
  834. # [21:33] <othermaciej> of what claim?
  835. # [21:33] <othermaciej> I have to go
  836. # [21:33] <othermaciej> ttyl
  837. # [21:33] <bewest> othermaciej: that vendors recieve blame
  838. # [21:33] <othermaciej> well this guy isn't blaming browser vendors for breaking sites
  839. # [21:34] <othermaciej> he is blaming them for not breaking *enough* sites
  840. # [21:35] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  841. # [21:35] <Dashiva> It takes all kinds to make a senseproof argument
  842. # [21:35] <bewest> I think the root is in the idea of laziness. the w3 stopped work on html and produced work that was unused. however, the vendors recieve the blame for this
  843. # [21:42] * Quits: maikmerten (n=maikmert@La751.l.pppool.de) ("Leaving")
  844. # [22:22] * Quits: ROBOd2 (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  845. # [22:27] * Joins: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com)
  846. # [22:28] * Quits: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com) (Client Quit)
  847. # [22:28] * Joins: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com)
  848. # [22:29] * Joins: timblair_ (n=timblair@host-87-74-129-183.bulldogdsl.com)
  849. # [22:30] <gsnedders> vendors are evil! we, the HTML WG, must produce our own perfect implementation regardless of technical limitations!
  850. # [22:30] * Quits: timblair_ (n=timblair@host-87-74-129-183.bulldogdsl.com) (Client Quit)
  851. # [22:30] * Quits: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com) (Client Quit)
  852. # [22:31] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("This computer has gone to sleep")
  853. # [22:34] * Joins: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com)
  854. # [22:35] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  855. # [22:38] * Joins: jcgregorio (i=chatzill@nat/ibm/x-e5662a3438a51738)
  856. # [22:56] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  857. # [22:58] * Quits: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com) (Connection timed out)
  858. # [23:04] * Quits: jcgregorio (i=chatzill@nat/ibm/x-e5662a3438a51738) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/0000000000]")
  859. # [23:10] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  860. # [23:21] * Quits: kingryan (n=kingryan@corp.technorati.com) (Read error: 110 (Connection timed out))
  861. # [23:23] * Quits: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) ("Leaving")
  862. # [23:31] * Joins: nickshanks (n=nicholas@home.nickshanks.com)
  863. # [23:35] * Joins: kingryan (n=kingryan@corp.technorati.com)
  864. # [23:52] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Read error: 104 (Connection reset by peer))
  865. # [23:58] * moeffju[away] is now known as moeffju
  866. # Session Close: Wed May 16 00:00:00 2007

The end :)