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

Options:

  1. # Session Start: Fri Jul 10 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:13] * Quits: poe_ (n=poe@adsl-ull-160-123.48-151.net24.it) ("Quit")
  4. # [00:16] * Quits: jennb (n=jennb@72.14.227.1) (Remote closed the connection)
  5. # [00:16] * Joins: jennb (n=jennb@72.14.227.1)
  6. # [00:17] * Joins: weinig (n=weinig@17.246.17.208)
  7. # [00:32] * Joins: pauld (n=pauld@92.40.177.117.sub.mbb.three.co.uk)
  8. # [00:43] <Lachy> I'm very surprised by Joshue's outright rejection of my rather practical proposal for making that particular use of canvas accessible.
  9. # [00:44] * Quits: tantek (n=tantek@adsl-76-202-153-93.dsl.pltn13.sbcglobal.net)
  10. # [00:46] * Parts: ojan (n=ojan@72.14.229.81)
  11. # [00:47] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  12. # [00:48] * Quits: pauld (n=pauld@92.40.177.117.sub.mbb.three.co.uk)
  13. # [00:49] * Quits: taf2_ (n=taf2@38.99.201.242)
  14. # [00:54] * Quits: jianli-win (n=jianli@72.14.227.1)
  15. # [00:55] * Joins: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se)
  16. # [00:58] * Parts: billmason (n=billmaso@ip104.unival.com)
  17. # [01:03] * Quits: archtech (n=stanv@83.228.56.37)
  18. # [01:08] * Joins: tantek (n=tantek@adsl-76-202-153-93.dsl.pltn13.sbcglobal.net)
  19. # [01:13] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-308f6b6c1542537b)
  20. # [01:14] <Hixie> oh Lachy's post reminds me that i need to follow up with the canvas issue
  21. # [01:15] * Quits: jwalden (n=waldo@nat/mozilla/x-57a77f21dfd979e0) (Remote closed the connection)
  22. # [01:16] * Joins: jwalden (n=waldo@nat/mozilla/x-d988f26c36d56765)
  23. # [01:23] * Quits: svl (n=me@86.87.68.167) ("And back he spurred like a madman, shrieking a curse to the sky.")
  24. # [01:23] <Lachy> Hixie, what did you think of my suggestions for making that canvas example accessible? Were they reasonable given the contstraints, or is Joshue right about it being ridiculous?
  25. # [01:24] <Hixie> i don't understand why you would use canvas for that use case at all
  26. # [01:25] <Hixie> (...and it already has an accessible version anyway)
  27. # [01:25] <Hixie> though that one seems to be missing the descriptions
  28. # [01:27] <Philip`> Lachy: Animated image maps sound ridiculuous to me
  29. # [01:28] <Hixie> man, changing table taint is gonna be such a pain
  30. # [01:28] <Philip`> If you're going to all the trouble of maintaining a kind of scene graph DOM, you might as well just use SVG and then you won't have all the weirdness and restrictiveness of image map shapes
  31. # [01:29] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-c36db5f90134b38c)
  32. # [01:30] <Hixie> that won't get you accessibility though
  33. # [01:30] <Hixie> (though for some reason, svg gets a free pass)
  34. # [01:31] <Philip`> s/ridiculuous/ridiculous/
  35. # [01:33] * Quits: dglazkov (n=dglazkov@nat/google/x-8746114d09aca911)
  36. # [01:35] <Lachy> Hixie, I know that specific page probably shouldn't use canvas, but there are lots of other interactive uses of canvas
  37. # [01:38] <Lachy> Philip`, I don't see why animated image maps would be ridiculous. If you wanted to support keyboard navigation while still providing the same visual layout, how would you do it without throwing out the canvas entirely?
  38. # [01:39] <Hixie> you can't do it properly right now without using either svg or crazy image map stuff
  39. # [01:40] * Quits: weinig (n=weinig@17.246.17.208)
  40. # [01:40] <Hixie> i don't know how to make it possible though
  41. # [01:42] <Philip`> The image map keyboard navigation order will be completely unrelated to the spatial positions of the areas, so it's not a good way to provide keyboard navigation of the graphical display
  42. # [01:43] <Hixie> keyboard navigation is the one aspect of making canvas accessible that i might be able to figure out
  43. # [01:43] <Lachy> if you know the positions of the areas on the screen, it's conceivable that you could calculate a reasonable tab order and either set tabindex or do the complicated thing of reording the area elements in the DOM
  44. # [01:43] <Philip`> Anything that gives a linear keyboard navigation order will be operating over a separate view of the data from the non-linear graphical view, so it seems unhelpfully complex to try to mix both the views together instead of just providing two independent views
  45. # [01:44] <Hixie> e.g. by providing a hook for the canvas to say how it is willing to handle focus movement while the canvas is focused
  46. # [01:44] <Philip`> (where one view might be <canvas> and the other view might be a <table> or <ul> or something)
  47. # [01:45] <Lachy> Philip`, providing 2 separate views doesn't solve the problem that Steve raised, which is that the original should be accessible, instead of having to maintain two completely different views
  48. # [01:46] * Quits: drostie (n=hopkins@5ED17066.cable.ziggo.nl) (Remote closed the connection)
  49. # [01:46] <Lachy> although, in this case, as I mentioned in my email, the table view is probably useful for more than just accessibility reasons
  50. # [01:47] * Sirisian_ is now known as Sirisian
  51. # [01:47] <Lachy> what if we took the concept of the image map and provided an API to declare a specific region of the canvas as being an active region which can respond to events?
  52. # [01:48] <Lachy> and which can recieve focus
  53. # [01:49] <Philip`> canvas.clearEventHandlers(); ctx.addEventHandlerOnClickInsideCurrentPath(function (evt) { ... })
  54. # [01:49] <Lachy> Then a backwards compatibility layer could possibly be provided by script libraries that generate equivalent image maps in the DOM
  55. # [01:50] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  56. # [01:51] * Joins: nessy (n=nessy@124-168-240-72.dyn.iinet.net.au)
  57. # [01:51] * Quits: cying (n=cying@70.90.171.153)
  58. # [01:52] <Lachy> Philip`, I was thinking something like: region = context.createActiveRegion(...); region.addEventListener(...);
  59. # [01:54] * Joins: weinig (n=weinig@17.246.17.208)
  60. # [01:55] <Hixie> that might be even better than doing it manually
  61. # [01:56] <Philip`> It'll be fun the first time someone creates a hundred active regions per frame, and forgets to delete them all before starting the next frame
  62. # [01:56] <Hixie> yeah that's the main reason i prefer the manual approach
  63. # [01:56] <Hixie> anyway, hopefully the wai will advise us as to the best approach
  64. # [01:57] <Lachy> Philip`, it might be better to just move the regions around, rather than delete and create new
  65. # [01:57] <aboodman> does anyone know of a demo anywhere of app cache that works in firefox 3.5?
  66. # [01:57] <aboodman> the web fails me
  67. # [01:59] <aboodman> uh, n/m, found something
  68. # [01:59] <Lachy> do we have a list of known uses canvas, like Yahoo Pipes, Bespin, and this Web Tools directory, from which we can analyse the use cases?
  69. # [01:59] <Lachy> Would be useful to have things like that listed in a wiki
  70. # [02:00] * Quits: tantek (n=tantek@adsl-76-202-153-93.dsl.pltn13.sbcglobal.net)
  71. # [02:00] <Philip`> Use cases for a declarative canvas interaction API, I guess?
  72. # [02:01] <Lachy> good, looks like we do have some http://esw.w3.org/topic/HTML/AddedElementCanvas#head-c43887ef27c016a20e53d16718ab16a398b6899d
  73. # [02:01] <roc> what is the difference between "declarative canvas interaction API" and "SVG"?
  74. # [02:01] <Lachy> Philip`, yeah. Any non-interactive canvas probably wouldn't need much beyond traditional fallback content, just like a regular image
  75. # [02:02] <Philip`> roc: Canvas is cooler than SVG
  76. # [02:03] <Philip`> It would be sensible to see how many of the use cases could be better handled with SVG, but I guess if the original developers chose canvas (despite it requiring lots of manual code to process input) then they must have had reasons
  77. # [02:04] <roc> performance tends to be one reason
  78. # [02:05] <roc> but it seems plausible that maintaing some set of parallel structures is likely to hurt performance
  79. # [02:05] <Lachy> roc, it's better to pave the cowpaths and let them keep using canvas in more accessible ways, than to try and get everyone to use SVG instead
  80. # [02:06] <roc> I don't agree
  81. # [02:06] * Quits: heycam (n=cam@124-168-95-60.dyn.iinet.net.au) ("bye")
  82. # [02:06] <roc> building a bunch of new canvas APIs and then discovering it's approximately as crappy as SVG would have been would be a terrible outcome
  83. # [02:07] <Lachy> no-one is suggesting building a set of APIs that are as crappy as SVG
  84. # [02:08] <roc> sure, no-one starts out with that intention
  85. # [02:08] <roc> anyway
  86. # [02:09] <Lachy> I'm not sure what you're trying to say now
  87. # [02:09] <Hixie> i'm sure the SVG WG didn't plan to make something "as crappy as SVG" as roc put it
  88. # [02:09] <Lachy> you started out questioning why we needed to develop declerative canvas APIs instead of just using SVG, but then said SVG is crappy. So I'm confused
  89. # [02:09] <Hixie> so why would your idea not end up being "as crappy as SVG"?
  90. # [02:09] <roc> I'm saying that adding some kind of parallel, accessible view of the canvas content may well destroy the reasons that people like to use canvas in teh first place
  91. # [02:10] <Lachy> roc, the new APIs suggested in here wouldn't be a parallel accessible view.
  92. # [02:10] <Lachy> the backwards compatible image map approach I suggested could be considered that way though
  93. # [02:11] <roc> you're talking about declaring "active regions"
  94. # [02:11] * Quits: jennb (n=jennb@72.14.227.1)
  95. # [02:11] <roc> how is that not a parallel, accessible view?
  96. # [02:12] <Lachy> because it wouldn't just serve accessibility reasons. Imagine being able to declare an active region, and then just listen for clicks there, instead of having to calculate where on the canvas the click occurred
  97. # [02:12] <Philip`> It's still a parallel view which is accessible
  98. # [02:13] <roc> the cases where canvas wins most over SVG are where the information is dense
  99. # [02:13] <roc> like graphs, or an RTS where every pixel is custom rendered
  100. # [02:14] <roc> in those cases, you'll have zillions of active regions
  101. # [02:14] <roc> if you only have a few active regions, then you probably only have a few shapes, and you can use SVG
  102. # [02:14] * Quits: weinig (n=weinig@17.246.17.208)
  103. # [02:14] <Philip`> http://philip.html5.org/demos/canvas/spritepick/example.html
  104. # [02:15] <roc> pretty cool
  105. # [02:15] <Lachy> roc, what other possible way is there that could solve the problem?
  106. # [02:15] <roc> I don't know
  107. # [02:15] <Philip`> That probably counts as dense information
  108. # [02:15] <roc> not all problems have solutions
  109. # [02:15] <Lachy> then how could we improve on the solution the idea to solve some of its own problems?
  110. # [02:15] <Philip`> What is the problem anyway?
  111. # [02:15] <roc> another problem with the active region approach is that it's bolted-on accessibility
  112. # [02:16] <roc> authors just won't use it
  113. # [02:16] <Lachy> the problem is making canvas accessible to people other than sighted people with a mouse
  114. # [02:16] <roc> or they'll use it wrong
  115. # [02:16] <roc> especially if there's a measurable performance hit
  116. # [02:17] <Hixie> Lachy: as i said, the other solution is to provide a hook for script so that when the canvas is focused, if the user tabs or directionally navigates the focus, the canvas can say "ok keep the focus in the canvas, i can handle that one"
  117. # [02:17] <Philip`> roc: They might use it if it's the easiest way to support interactivity (i.e. clicking on regions), and a side-effect is that it can be exposed in a more accessible way
  118. # [02:17] <Lachy> there doesn't really seem to be a way for it to not be bolt on accessibility. But, as I said before, it could be leveraged for more than just accessibility purposes
  119. # [02:17] <Philip`> roc: It's kind of a pain to put onclick on the canvas and then have to manually work out which object was clicked on, so an API that makes that easier might get used by people who don't care about accessibility
  120. # [02:18] <Lachy> Hixie, that sounds far more complicated than letting the browser itself help out
  121. # [02:18] <roc> Philip`: maybe, except for the problem I noted about having large numbers of regions
  122. # [02:18] <Hixie> Lachy: maybe, i haven't compared the resulting code
  123. # [02:19] <roc> If the canvas contents are changing, then you have to maintain the set of regions and their geometry
  124. # [02:19] <roc> seems to me that's probably actually harder than writing your own picker code
  125. # [02:19] <roc> maintaining cached stuff persistently is almost always harder than just recomputing something whenever you need it
  126. # [02:20] <Philip`> I'm assuming you could just destroy and recreate all the regions every frame, at the same time as you're recreating all the rendered paths
  127. # [02:20] <roc> if you're doing that, then the actual code that walks the regions to do picking is relatively easy
  128. # [02:20] <Philip`> (Hooray for garbage collectors)
  129. # [02:21] <roc> maybe if you did beginRegion(...); draw draw draw; endRegion(...)
  130. # [02:25] <Lachy> interesting idea. So the region would include any pixel that was drawn on
  131. # [02:27] <roc> yeah
  132. # [02:28] <Philip`> What does "drawn on" mean?
  133. # [02:29] <roc> whatever we want it to mean
  134. # [02:29] <roc> that would be more convenient than writing your own custom picking code, so I can believe that people might actually use it
  135. # [02:29] <roc> and it might perform OK, since the browser can compute bounding boxes for you
  136. # [02:29] <Philip`> I can imagine it would relatively common to e.g. draw a shadowed box, and want to respond to the mouse being over the box and not its shadow
  137. # [02:29] <roc> and probably already does for invalidation etc
  138. # [02:30] <Philip`> but also to draw an image with transparency, and want to respond to the mouse being over non-zero-alpha bits
  139. # [02:30] * Joins: othermaciej (n=mjs@17.246.18.9)
  140. # [02:32] <jwalden> man, wikipedia is being amazingly aggressive with their video support
  141. # [02:34] * aroben is now known as aroben|away
  142. # [02:35] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  143. # [02:36] * Quits: MikeSmith (n=MikeSmit@EM114-48-19-210.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  144. # [02:43] <ezyang> It's... it's... taint mode changes! (Runs away and screams)
  145. # [02:44] <ezyang> Pretty large changeset too. That makes me very unhappy
  146. # [02:44] * Joins: webben_ (n=benh@82.152.35.195)
  147. # [02:44] <Hixie> sorry!
  148. # [02:45] <Hixie> it shouldn't actually be that hard to code
  149. # [02:45] <Hixie> most of the changes were in the examples
  150. # [02:45] <Hixie> assuming your tokeniser already groups characters, you don't need the new insertion mode
  151. # [02:48] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-c36db5f90134b38c)
  152. # [02:53] <Hixie> http://www.lebgeeks.com/forums/viewtopic.php?id=5446&action=new
  153. # [02:56] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  154. # [02:56] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
  155. # [03:02] <Lachy> where do people get the idea that HTML5 is officially released?
  156. # [03:03] <Hixie> it is officially released
  157. # [03:03] <Hixie> it's been officially released since about 2004
  158. # [03:03] * Joins: MikeSmith (n=MikeSmit@EM114-48-205-137.pool.e-mobile.ne.jp)
  159. # [03:03] <Lachy> it seems more like that the forum post meant finalised, not just a public draft
  160. # [03:04] <Hixie> what does "finalised" mean
  161. # [03:04] <Hixie> you mean like xhtml2? :-)
  162. # [03:04] <Lachy> no, I mean like being finished and published as a Rec
  163. # [03:05] <Lachy> but if that's not what the post meant, then it's not clear why he would use langauge like "Officially Released" in that context
  164. # [03:06] <Lachy> unless he thinks this is the first time it's been public
  165. # [03:07] <Hixie> by the time html5 is a REC, nobody will care
  166. # [03:07] <Hixie> we'll be all working on HTML6 or even HTML7 (assuming we don't go with what I would like to do, which is just make HTML a living document with no meaningless versioning)
  167. # [03:08] * Quits: MikeSmith (n=MikeSmit@EM114-48-205-137.pool.e-mobile.ne.jp) (Client Quit)
  168. # [03:09] <Lachy> so you would just keep it like it is on the whatwg copy with section specific status markers forever?
  169. # [03:11] <Hixie> sure
  170. # [03:12] * Joins: MikeSmith (n=MikeSmit@EM114-48-205-137.pool.e-mobile.ne.jp)
  171. # [03:14] <Lachy> we could effectively do that if we just treat the Recs as stable snapshots, and keep going with the same spec instead of starting fresh each time (which wouldn't be a good idea, anyway)
  172. # [03:15] * Quits: ap (n=ap@nat/apple/x-3a2d0a231aaedbbb)
  173. # [03:15] <Hixie> that would require a change to the w3c process though
  174. # [03:16] <Hixie> you can't do LC->CR->PR->REC if you're just doing RECs as snapshots
  175. # [03:17] <Lachy> not really, since each time you begin work on the next version, you just fork the spec into, e.g. an HTML5 or HTML6 branch, which then continues along the Rec track while the trunk keeps going
  176. # [03:18] <Lachy> just like how software branches quite happily go through alphas->betas->release candidates->final
  177. # [03:21] <Hixie> oh hell, i'm not maintaining two branches of html5
  178. # [03:21] <Hixie> it's bad enough for code
  179. # [03:21] <Hixie> i'm not maintaining a 15 year branch
  180. # [03:22] <Lachy> how else do you intend us to start on HTML5 within the current w3c process then?
  181. # [03:22] <Lachy> *HTML6
  182. # [03:25] <Hixie> we can't, with the current process
  183. # [03:25] <Hixie> but i think the problem is the process
  184. # [03:25] <Lachy> but with your model, it seems difficult for any specific section to ever be marked stable and stay that way for very long
  185. # [03:26] <Hixie> yup
  186. # [03:26] <Hixie> that's the point
  187. # [03:26] <Hixie> there is no stability here
  188. # [03:26] <Hixie> it's an ever-evolving platform
  189. # [03:26] <Hixie> the specs should reflect that
  190. # [03:27] <Lachy> but by publishing a stable snapshot, it allows implementers to clearly distinguish the stable sections from the new unstable sections
  191. # [03:28] <Lachy> so e.g. if video becomes widely implemented with its current feature set, and then you want to go add some new APIs after that, the new unstable stuff would be mixed in with the previously stable stuff
  192. # [03:29] <Hixie> i disagree with your use of the word "clearly"
  193. # [03:30] <Hixie> if we're trying to make it easier to recognise new features, then we should work on that specifically
  194. # [03:30] <Hixie> having said that, i don't know how to do that, especially when the new features integrate deeply with e.g. navigation
  195. # [03:33] <Lachy> I suppose I can understand why maintaining forks won't work too well. It doesn't really work too well for XHR and XHR2, like Anne is doing
  196. # [03:35] <Hixie> it doesn't ever work well
  197. # [03:35] <Hixie> it only vaguely works for software projects when they have very short lifetimes (weeks at most) and few checkins (just patches for crashes and stop-ship bugs)
  198. # [03:36] <Hixie> anything that has to either track another branch, or have bugs fixed in two or more branches, or merge back into another branch later, is a disaster
  199. # [03:42] * Quits: yshin (n=yshin@72.14.227.1)
  200. # [03:43] <sebmarkbage> There is never going to be anything like stable sections. I'm currently implementing drag & drop APIs with backward compatibility. They're largely implemented but there are lots of little quirks that live through major releases. I think it'll remain like that for quite a while.
  201. # [03:45] <Lachy> sebmarkbage, in which browser?
  202. # [03:46] * Quits: dbaron (n=dbaron@nat/mozilla/x-d9a204eeb91595a2) ("8403864 bytes have been tenured, next gc will be global.")
  203. # [03:47] <sebmarkbage> I'm implementing JS legacy compatibilty for MooTools and while doing that, working on patches for WebKit.
  204. # [03:47] <othermaciej> software is never perfect or frozen, yet we still ship it every once in a while
  205. # [03:47] <othermaciej> not sure if this is a plausible model for specs
  206. # [03:51] <sebmarkbage> That's the essence of HTML 5 IMHO. If you could do perfect frozen models, it'd be called XHTML 2. But the internet is a moving organism of legacy code. That somehow works.
  207. # [03:51] * Quits: nessy (n=nessy@124-168-240-72.dyn.iinet.net.au) ("This computer has gone to sleep")
  208. # [03:52] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  209. # [03:59] * Quits: jianli (n=jianli@72.14.227.1) (Read error: 110 (Connection timed out))
  210. # [04:05] * Joins: archtech (n=stanv@83.228.56.37)
  211. # [04:23] * Quits: othermaciej (n=mjs@17.246.18.9) (Remote closed the connection)
  212. # [04:24] * Joins: othermaciej (n=mjs@17.203.15.190)
  213. # [04:48] * Joins: weinig (n=weinig@17.246.17.208)
  214. # [04:48] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  215. # [04:50] * Quits: bgalbraith (n=bgalbrai@71.202.109.116) (Client Quit)
  216. # [04:54] <ezyang> Hmm, new table handling algo doesn't seem too hard to implement
  217. # [04:55] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  218. # [04:55] <ezyang> Go go PHP
  219. # [05:12] * Quits: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se) ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
  220. # [05:19] * Quits: weinig (n=weinig@17.246.17.208)
  221. # [05:21] * Joins: nessy (n=nessy@124-168-240-72.dyn.iinet.net.au)
  222. # [05:31] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  223. # [05:40] * Quits: MikeSmith (n=MikeSmit@EM114-48-205-137.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  224. # [05:42] * Joins: excrypf (n=nogah@118.71.79.116)
  225. # [05:43] <ezyang> Wtf. None of our tests started failing with the new taint mode
  226. # [05:43] <ezyang> That's not acceptable!
  227. # [05:56] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  228. # [05:56] <ezyang> What do the vertical lines in the "handling parser errors" section mean?
  229. # [06:08] * Joins: MikeSmith (n=MikeSmit@EM114-51-47-165.pool.e-mobile.ne.jp)
  230. # [06:09] <ezyang> Landed!
  231. # [06:11] <ezyang> Someone should doublecheck my test cases
  232. # [06:28] <roc> Tom Lord is frustrating me
  233. # [06:30] <othermaciej> would www-font be at all useful in any case if not for Tom Lord?
  234. # [06:31] <othermaciej> roc: btw, I'm pretty sure I told Hixie that canPlayType would cause the exact mistake you made to be extremely common
  235. # [06:31] <othermaciej> I wonder if it's too deployed to change now :-(
  236. # [06:31] <roc> I told him too
  237. # [06:31] <othermaciej> at the very least, it should not have been named to sound like it returns a boolean
  238. # [06:31] <roc> I make that mistake about every time I use it
  239. # [06:31] <othermaciej> something like playabilityForType()
  240. # [06:31] <othermaciej> or to make the "no" case return false
  241. # [06:31] <othermaciej> or split into mightPlayType() and canDefinitelyPlayType()
  242. # [06:31] <roc> yeah
  243. # [06:32] <roc> having the "no" case return false would screw with non-JS bindings
  244. # [06:32] <roc> Would www-font be useful? Maybe.
  245. # [06:32] <roc> at least it would be less painfully unuseful.
  246. # [06:33] <othermaciej> roc: I didn't even know your code was buggy from memory, it was only when I tested that I found it was always saying "YES"
  247. # [06:33] <othermaciej> (wanted to confirm that our canPlayType bug was properly fixed)
  248. # [06:33] <roc> hehe
  249. # [06:33] <othermaciej> so basically, if you and I can't understand how the API works, despite commenting on it in detail in the past, it is clearly broken
  250. # [06:33] <roc> yes, that was my snarky point
  251. # [06:34] <roc> I also implemented it
  252. # [06:35] <Hixie> i thought i'd fixed the things you mentioned, didn't realise i'd failed to address this particular point. i agree that we should fix this.
  253. # [06:36] <roc> returning the empty string would work
  254. # [06:36] <roc> we could probably ram that into a Firefox update
  255. # [06:36] * Quits: nessy (n=nessy@124-168-240-72.dyn.iinet.net.au) ("This computer has gone to sleep")
  256. # [06:37] <othermaciej> empty string would work for JS, yes
  257. # [06:37] <othermaciej> in other languages, it would be harder to make it accidentally do a boolean check
  258. # [06:37] <roc> yeah
  259. # [06:37] <othermaciej> wait, I'm not sure as to Java
  260. # [06:38] <othermaciej> if (!str) is probably a null check in Java
  261. # [06:38] <roc> it's not
  262. # [06:38] <othermaciej> oh good
  263. # [06:38] * roc likes Java and doesn't care how unfashionable that makes him
  264. # [06:39] <othermaciej> it's not quite too late to get "" in the next Safari update if it's decided, like, today or tomorrow
  265. # [06:39] <othermaciej> (not that it's shipping tomorrow but I won't be able to sneak it in after that)
  266. # [06:39] <Hixie> spec updated to say "" instead of "no".
  267. # [06:41] <Hixie> roc: re www-font... given that microsoft have (as i understand it) said they won't do TTF, is there anything to discuss?
  268. # [06:41] <Hixie> i've only been skimming the discussion
  269. # [06:42] <roc> Hixie: thanks re. canPlayType
  270. # [06:42] <othermaciej> Hixie: thanks - I'll try to sneak it in
  271. # [06:43] <roc> Hixie: There is potential value in jfkthame's ZOT proposal, or something like it, independent of what MS does
  272. # [06:44] <roc> IMHO
  273. # [06:45] <othermaciej> roc: link?
  274. # [06:46] <roc> I wish Gmail would find public archived versions of messages
  275. # [06:46] <Hixie> ZOT?
  276. # [06:47] <roc> hehe ... www-font traffic: Jan-March: 1, April-June: 54, July-September: 415
  277. # [06:48] <Hixie> that's not a good trend
  278. # [06:48] <roc> considering we're 10 days into July
  279. # [06:49] <roc> http://lists.w3.org/Archives/Public/www-font/2009JulSep/0018.html
  280. # [06:50] * Quits: archtech (n=stanv@83.228.56.37)
  281. # [06:52] <doublec> are "probably" and "maybe" the only return values possible from canPlayType?
  282. # [06:53] <doublec> oh, and empty string, missed that
  283. # [06:53] <Hixie> right
  284. # [06:56] * Quits: excrypf (n=nogah@118.71.79.116) ("Leaving.")
  285. # [07:02] <MikeSmith> yey - just scored a print copy of chrome japanese comic
  286. # [07:05] * weinig is now known as weinig|away
  287. # [07:07] <roc> pah
  288. # [07:07] <roc> othermaciej got his patch in first
  289. # [07:07] <roc> but I claim it's only because they have fewer tests to update that use canPlayType
  290. # [07:08] <Hixie> hah
  291. # [07:10] <othermaciej> actually, what happened is that olliej (who didn't even see this conversation) saw on twitter that the spec changed and immediately coded a patch
  292. # [07:10] * Joins: slightlyoff (n=slightly@204.14.154.228)
  293. # [07:10] <othermaciej> I was gonna do it to morrow
  294. # [07:11] * Joins: slightlyoff_ (n=slightly@72.14.224.1)
  295. # [07:11] * Joins: nessy (n=nessy@r125-63-191-29.cpe.unwired.net.au)
  296. # [07:11] <doublec> hopefully it doesn't break any existing canPlayType usage
  297. # [07:11] <roc> doublec: it probably will
  298. # [07:11] <roc> however
  299. # [07:11] * Quits: dimich (n=dimich@72.14.227.1)
  300. # [07:11] <roc> this seems to be a situation where most people using the API are probably using it incorrectly already
  301. # [07:12] <doublec> Not from what I've seen
  302. # [07:12] <doublec> But they check for "probably" and "maybe" explicitly and fail on anything else
  303. # [07:12] <doublec> it seems
  304. # [07:12] * Quits: slightlyoff (n=slightly@204.14.154.228) (Read error: 60 (Operation timed out))
  305. # [07:12] <roc> that's OK
  306. # [07:12] <doublec> yep
  307. # [07:12] <roc> if you test on multiple browsers you probably get the "no" case OK
  308. # [07:12] <roc> if you don't, you lose
  309. # [07:14] <roc> hmm, I'm up at the beach and there's a storm warning advising everyone to stock up on food for 2-3 days
  310. # [07:14] <roc> if I'm offline for a while, that'll be why
  311. # [07:18] * Quits: MikeSmith (n=MikeSmit@EM114-51-47-165.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  312. # [07:19] <Hixie> good to know
  313. # [07:20] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  314. # [07:33] * Joins: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net)
  315. # [07:34] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
  316. # [07:41] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  317. # [07:41] * Quits: jwalden (n=waldo@nat/mozilla/x-d988f26c36d56765) ("->home")
  318. # [07:43] * Quits: aroben|away (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  319. # [07:59] * Quits: othermaciej (n=mjs@17.203.15.190)
  320. # [08:05] * Joins: ginger (n=nessy@r125-63-185-209.cpe.unwired.net.au)
  321. # [08:17] * Quits: dolske (n=dolske@nat/mozilla/x-21cddf4493c18bcd) (Read error: 110 (Connection timed out))
  322. # [08:17] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  323. # [08:21] * Quits: nessy (n=nessy@r125-63-191-29.cpe.unwired.net.au) (Read error: 110 (Connection timed out))
  324. # [08:27] * Joins: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  325. # [08:27] * Quits: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net) (Client Quit)
  326. # [08:29] * Joins: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  327. # [08:33] <JPKe> 3
  328. # [08:34] * Quits: webben_ (n=benh@82.152.35.195) (Read error: 110 (Connection timed out))
  329. # [08:34] * Quits: weinig|away (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  330. # [08:35] * Parts: JPKe (i=jp@193.184.160.99)
  331. # [08:38] * Quits: Sirisian (n=Sirisian@ppp-70-229-33-42.dsl.klmzmi.ameritech.net) (Read error: 110 (Connection timed out))
  332. # [08:40] * Quits: bgalbraith (n=bgalbrai@71.202.109.116)
  333. # [08:46] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  334. # [08:48] <hsivonen> so, I think I should implement HTML5-compliant document.write timing behavior
  335. # [08:49] <hsivonen> basically prevent it from timeouts and such
  336. # [08:49] <hsivonen> is it correct that insertion point is
  337. # [08:49] <hsivonen> 1) Not defined when document.write runs synchronously and is not breaking on </script>
  338. # [08:50] <hsivonen> 2) Defined when document.write breaks on </script>
  339. # [08:50] <hsivonen> 3) Defined when normal tokenization executes inline script on </script>
  340. # [08:51] <hsivonen> 4) Defined when an external non-defer script's load completes and it is run.
  341. # [08:51] <hsivonen> 5) (Not yet but per sicking's email will be) when the network stream has ended, there are only defer scripts left and a defer scripts is executed
  342. # [08:52] <hsivonen> 6) Not defined at any other time
  343. # [08:52] <hsivonen> Correct?
  344. # [08:53] * Joins: archtech (n=stanv@83.228.56.37)
  345. # [08:58] * Joins: pesla (n=retep@procurios.xs4all.nl)
  346. # [09:05] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  347. # [09:08] * Quits: ginger (n=nessy@r125-63-185-209.cpe.unwired.net.au) ("This computer has gone to sleep")
  348. # [09:12] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  349. # [09:17] * hsivonen struggles with the UI of the spec
  350. # [09:21] <hsivonen> hmm. diveintomark.org seems broken
  351. # [09:22] * Joins: drostie (n=hopkins@5ED17066.cable.ziggo.nl)
  352. # [09:24] * Joins: Khazou (n=Khazou@AReims-152-1-151-72.w90-7.abo.wanadoo.fr)
  353. # [09:47] <hsivonen> what's the deal with SVG scripts setting the parser pause flag to true before running?
  354. # [09:52] <hsivonen> #dfnReturnLink-n for any value of n broken for everyone or just for me?
  355. # [10:00] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  356. # [10:00] * Quits: archtech (n=stanv@83.228.56.37)
  357. # [10:00] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  358. # [10:01] * Joins: aboodman2 (n=aboodman@72.14.229.81)
  359. # [10:02] * Joins: zdobersek (n=zan@cpe-92-37-65-44.dynamic.amis.net)
  360. # [10:04] * Quits: bgalbraith (n=bgalbrai@71.202.109.116)
  361. # [10:05] <hsivonen> Hixie: is there a maximum for script nesting level that follows from everything else?
  362. # [10:05] * Joins: gsnedders (n=gsnedder@pat.se.opera.com)
  363. # [10:10] * Joins: nessy (n=nessy@124-168-240-72.dyn.iinet.net.au)
  364. # [10:10] * Quits: aboodman (n=aboodman@72.14.229.81) (Read error: 110 (Connection timed out))
  365. # [10:11] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) (Read error: 110 (Connection timed out))
  366. # [10:12] * Joins: heycam (n=cam@124-168-95-60.dyn.iinet.net.au)
  367. # [10:13] <hsivonen> Hixie: it seems that Gecko doesn't execute a script if the script is in a noscript or noembed container in the tree at the time that execution is attempted
  368. # [10:15] <hsivonen> s/execution/running/ to use HTML5 terms
  369. # [10:16] <hsivonen> s/noscript/noframes/
  370. # [10:17] * Joins: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net)
  371. # [10:18] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 104 (Connection reset by peer))
  372. # [10:24] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  373. # [10:28] * Joins: heycam` (n=cam@124-168-95-60.dyn.iinet.net.au)
  374. # [10:33] * Quits: heycam` (n=cam@124-168-95-60.dyn.iinet.net.au) (Client Quit)
  375. # [10:33] * Joins: Phae (n=phaeness@cpc2-acto6-0-0-cust747.brnt.cable.ntl.com)
  376. # [10:42] <hsivonen> Hixie: does this if block comply with HTML5? http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptLoader.cpp#550
  377. # [10:46] <hsivonen> Hixie: have you looked at the Gecko script blocker concept? does HTML5 deal with it somehow?
  378. # [10:47] <hsivonen> Hixie: as far as I can tell, HTML5 executes inline non-async scripts immediately, but Gecko may spin the event loop if there's a script blocker in effect
  379. # [10:47] * Joins: ROBOd (n=robod@89.122.216.38)
  380. # [10:52] <hsivonen> Hixie: the script nesting level concept was removed from Gecko a while ago
  381. # [10:53] <hsivonen> Hixie: while it was in Gecko, did it inspire the current spec text?
  382. # [10:54] * Joins: virtuelv_ (n=virtuelv@pat-tdc.opera.com)
  383. # [10:54] * Quits: virtuelv_ (n=virtuelv@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  384. # [10:56] * Joins: webben (n=benh@nat/yahoo/x-d5f4e17b59924115)
  385. # [11:04] <hsivonen> Hixie: so, if a script's parent has been moved to a different document and the script does document.write(), does it blow away the other document?
  386. # [11:13] <hsivonen> It seems that if I want to avoid seriously refactoring Gecko's script execution code
  387. # [11:13] <hsivonen> (and I want to avoid it)
  388. # [11:14] <hsivonen> I need to make scripts not only know their document but their originating parser
  389. # [11:14] * Quits: zdobersek (n=zan@cpe-92-37-65-44.dynamic.amis.net) ("Leaving.")
  390. # [11:14] <hsivonen> well, I suppose having a weak ref to the parser from parser-inserted script nodes isn't too serious bloat...
  391. # [11:16] <hsivonen> cause if I don't make them know their originating parser and scripts are moved between documents that both have active parsers, bad stuff could happen, I think
  392. # [11:21] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  393. # [11:31] * Quits: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net) (Read error: 54 (Connection reset by peer))
  394. # [11:33] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  395. # [12:04] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  396. # [12:30] * Joins: adactio (n=adactio@host86-132-125-223.range86-132.btcentralplus.com)
  397. # [12:30] <Lachy> http://arstechnica.com/web/news/2009/07/apple-proposes-http-streaming-feature-as-a-protocol-standard.ars
  398. # [12:32] <hsivonen> the basic idea would work also for Ogg, right? since you can concatenate Ogg pieces rather freely
  399. # [12:33] <hsivonen> I'm sure the Apple rep dealing with this at the IETF will have a fun time with all the RTSP proponents
  400. # [12:33] <kinetik> depends what the unpublished patent(s) related to that draft are
  401. # [12:33] <kinetik> http://datatracker.ietf.org/ipr/1142/
  402. # [12:35] <hsivonen> "In the event that these patents issue, Apple
  403. # [12:35] <hsivonen> agrees, upon written request from a party, to negotiate with that party a
  404. # [12:35] <hsivonen> non-sublicenseable license to the Essential Claims under reasonable and
  405. # [12:35] <hsivonen> non-discriminatory terms and conditions, solely to the extent necessary to
  406. # [12:36] <hsivonen> implement required portions of the Informational Internet Draft,"
  407. # [12:36] <hsivonen> non-sublicensable RAND...
  408. # [12:36] <hsivonen> way to go IETF
  409. # [12:37] * Quits: webben (n=benh@nat/yahoo/x-d5f4e17b59924115) ("leaving")
  410. # [12:37] * Joins: webben (n=benh@nat/yahoo/x-d0cc4537b033b12b)
  411. # [12:38] * Quits: webben (n=benh@nat/yahoo/x-d0cc4537b033b12b) (Client Quit)
  412. # [12:38] * Joins: webben (n=benh@nat/yahoo/x-fe983a9d20b0b4c0)
  413. # [12:44] * Philip` keeps getting RTSP and RTMP mixed up
  414. # [12:46] * hsivonen wonders if the BBC is still using Real's formats for something
  415. # [12:46] <hsivonen> looks like it
  416. # [12:46] <Philip`> They still provide radio streams using Real
  417. # [12:47] <Philip`> (but default to Flash)
  418. # [12:47] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  419. # [12:47] <hsivonen> I guess Flash has hurt Real pretty seriously
  420. # [12:48] <Philip`> Looks like they also provide WMA of radio streams
  421. # [12:49] <jgraham> Yeah the BBC tries pretty hard to cover all its bases and is pretty reluctant to remove old stuff
  422. # [12:49] * hsivonen hasn't used RealPlayer in ages
  423. # [12:50] <Philip`> (get_iplayer says "flashaac1,flashaac2,realaudio,wma" for radio streams; "flashaac1,flashaudio,iphone,realaudio" for old radio programmes)
  424. # [12:52] <Philip`> ("flashnormal" for live TV streams; "flashhd1,flashhigh3,flashlow1,flashlow2,flashnormal,flashvhigh2,iphone,n95_wifi,subtitles" for old TV programmes (at least ones available in HD))
  425. # [12:53] * Joins: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se)
  426. # [12:54] * Philip` likes their HD content - 1280x720 H.264 looks pretty good, and it's only 1.4GB per hour
  427. # [12:56] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  428. # [12:56] <Philip`> (Also, no adverts and I don't even have to pay the TV Licensing fee)
  429. # [12:59] <Lachy> there could well be prior art on it anyway, since play lists have been around for years and the idea of splitting videos up and playing them sequentially isn't new
  430. # [13:00] * Quits: webben (n=benh@nat/yahoo/x-fe983a9d20b0b4c0) ("Lost terminal")
  431. # [13:02] <Lachy> though it sucks that Apple decided to include the equivalent of the broadcast flag :-(
  432. # [13:02] <hsivonen> oh there's even that kind of thing lurking in there :-(
  433. # [13:03] <Lachy> yeah, it was mentioned in the ars technica article
  434. # [13:03] <Lachy> Apparently it's just a flag that indicates whether clients are allowed to cache it or not
  435. # [13:04] <Lachy> so of course it's a completely inneffective form of DRM, but it could well be subject to anti-circumvention clauses like the broadcast flag was
  436. # [13:07] * Joins: kenkam (n=kenkam@host86-144-77-90.range86-144.btcentralplus.com)
  437. # [13:08] * Joins: archtech (n=stanv@83.228.56.37)
  438. # [13:10] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 104 (Connection reset by peer))
  439. # [13:11] <hsivonen> is async an HTML5 invention or an IE thing?
  440. # [13:11] <hsivonen> on scripts
  441. # [13:13] * Quits: sayrer__ (n=chatzill@user-0cceh2r.cable.mindspring.com) (Read error: 110 (Connection timed out))
  442. # [13:15] <Lachy> I think it's an HTML5 invention
  443. # [13:18] <hsivonen> Lachy: OK. thanks
  444. # [13:20] <Lachy> hsivonen, does IE even support it?
  445. # [13:21] <hsivonen> Lachy: I don't see it on MSDN
  446. # [13:21] <Lachy> nor do I
  447. # [13:22] <hsivonen> If authors start using the async attribute ahead of browsers, the feature will be pretty much poisoned...
  448. # [13:22] <Lachy> is there any evidence that they are?
  449. # [13:22] <Lachy> I've not seen much written about it at all
  450. # [13:24] <hsivonen> Lachy: there seems to be existence proof that it has been used in the wild once
  451. # [13:24] <hsivonen> Lachy: view source on http://samaxes-demos.appspot.com/samaxesjs/toc-jquery.html
  452. # [13:24] <Lachy> it probably wouldn't hurt too much though, as long as authors don't use it and then stupidly rely on the script executing synchronously
  453. # [13:25] <hsivonen> "as long as", yeah...
  454. # [13:25] <Lachy> yeah, I don't have much faith in authors not doing stupid things either
  455. # [13:26] <Lachy> for many cases, they'd be better off using defer instead, since the difference between waiting for the script to be available and the page to finish downloading would be negligable in most cases
  456. # [13:27] <Lachy> and at least defer is supported by IE
  457. # [13:29] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  458. # [13:31] <Rik|work> and firefox now ?
  459. # [13:32] <Lachy> I haven't heard about it being supported in firefox, but possibly
  460. # [13:32] * Joins: zdobersek (n=zan@cpe-92-37-74-10.dynamic.amis.net)
  461. # [13:33] <Rik|work> http://hacks.mozilla.org/2009/06/defer/
  462. # [13:34] <Lachy> I'm quite surprised that such a useful feature has taken so long to be deployed in other browsers
  463. # [13:35] <Lachy> especially given that people have used increasingly complex methods of achieving effectively the same result
  464. # [13:42] * Quits: zdobersek (n=zan@cpe-92-37-74-10.dynamic.amis.net) (Remote closed the connection)
  465. # [13:50] * Quits: kenkam (n=kenkam@host86-144-77-90.range86-144.btcentralplus.com) (Success)
  466. # [13:55] * Joins: zdobersek (n=zan@cpe-92-37-74-10.dynamic.amis.net)
  467. # [14:04] * Joins: taf2_ (n=taf2@static-71-127-149-10.bltmmd.fios.verizon.net)
  468. # [14:28] * Joins: excrypf (n=nogah@118.71.77.84)
  469. # [14:40] * Quits: danbri (n=danbri@unaffiliated/danbri) ("going back to danbri.org")
  470. # [14:50] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 60 (Operation timed out))
  471. # [14:52] * Joins: pmuellr (n=pmuellr@nat/ibm/x-5665b245ef06aa54)
  472. # [14:56] * Quits: adactio (n=adactio@host86-132-125-223.range86-132.btcentralplus.com)
  473. # [15:20] <Lachy> I was going to see if I could have a go at doing some video codec comparisons between theora, dirac and h.264, but with a slightly improved methodology over what was used here http://people.xiph.org/~greg/video/ytcompare/comparison.html
  474. # [15:20] <Lachy> unfortunately, I can't obtain ffmpeg right now
  475. # [15:21] <Philip`> Are you intending to compare the quality of the codec format, or the quality of ffmpeg's implementation of them?
  476. # [15:22] <Lachy> one problem with that previous methodology was that the source video he created used a lossy codec, and so artifacts from that were passed through to the the resultant h.264 and theora versions
  477. # [15:23] <Philip`> That's how codecs get used in practice
  478. # [15:23] <Lachy> Philip`, from what I've read, ffmpeg seems to have the latest version of schroedinger in it for encoding dirac, and it also allows me to encode the Big Buck Bunny images into a lossless source video
  479. # [15:24] <hsivonen> Lachy: I'd expect quality 100 MJPEG not to invalidate the methodology
  480. # [15:24] <Philip`> People don't upload lossless videos to YouTube - they just copy the MPEG-2 that their camera recorded or the XviD that they generated on their computer or whatever
  481. # [15:24] <hsivonen> Lachy: also, non-computer-generated video will have been through DCT anyway
  482. # [15:24] <Lachy> it's better to eliminate unnecessary losses in quality before the final encodes
  483. # [15:24] <hsivonen> either as MJPEG or as DV
  484. # [15:25] <hsivonen> Lachy: the interesting thing is to test with the kind of crappy source material that gets uploaded to YouTube
  485. # [15:25] <hsivonen> Philip`: whose camera records MPEG-2?
  486. # [15:25] <Philip`> As someone mentioned on the list, any comparison should look at varying kinds of source material, e.g. clean CG animations and camera-phone videos and cartoons and TV recordings etc
  487. # [15:26] * hsivonen thought cameras were DV, MJPEG and H.264
  488. # [15:26] <Philip`> since some codecs might be good at some and rubbish at others
  489. # [15:26] <Philip`> hsivonen: No idea, I just made it up
  490. # [15:26] <hsivonen> oh, and many camera phones are MPEG-4 SP
  491. # [15:28] <Lachy> no, the interesting thing is to elimiate as many variables as possible and ensure you're only testing the quality of the encoders
  492. # [15:29] <Philip`> Lachy: In that case, maybe you should use a pure black image as the source video, to fully eliminate the variability in the input
  493. # [15:29] <Lachy> also, I'm not enitrely sure that quality 100 MJPEG is lossless, and he also had another lossy step before that when he resampled the images to 480x270 using ImageMagick
  494. # [15:30] <hsivonen> Lachy: I think the right thing to test is substantial random sample of raw YouTube material with YouTube's current H.264 encode and Thusnelda with constant settings for the whole sample per Thusnelda config
  495. # [15:30] <hsivonen> Lachy: because in practice YT doesn't hand tune
  496. # [15:30] <hsivonen> Lachy: because in practice, it's a comptetition against H.264 as practiced by YT--not ideal H.264 encode
  497. # [15:31] <hsivonen> Lachy: and because real world has crappy source video
  498. # [15:31] <hsivonen> Lachy: as long as you don't crop after 100 MJPEG, MJPEG should be fine
  499. # [15:31] <Lachy> so, that doesn't mean it's not useful to have true comparison that only tests the codecs in a way that is unaffected by other external factors
  500. # [15:32] <hsivonen> (since the JPEG blocks will align with the video codec blocks anyway)
  501. # [15:32] <hsivonen> (and video codecs most likely do something sufficiently DCT-like anyway)
  502. # [15:32] <hsivonen> Lachy: depends on what you are trying to prove
  503. # [15:33] <Philip`> Video compression is all about tradeoffs, and if you only use one source video then you're only seeing one data point and have no idea what tradeoffs were made that harm other equally-important inputs
  504. # [15:33] <Lachy> anyway, my plan was to encode the PNGs into a lossless huffyuv encoded video (since that's supported by ffmpeg) and then use that as the source for comparing dirac and theora, and possibly h.264
  505. # [15:33] <jgraham> Lachy: I think it is well known that H.264 is better in an ideal world
  506. # [15:33] * Joins: sbublava (n=stephan@77.119.142.2.wireless.dyn.drei.com)
  507. # [15:33] <jgraham> The question is is it substantially better under real wworld conditions
  508. # [15:33] <hsivonen> Lachy: what kind of camera are you getting your video from?
  509. # [15:34] <Philip`> Lachy: RGB to YUV is kind of lossy, I think
  510. # [15:34] <Lachy> hsivonen, I'm using the Big Buck Bunny images that were used in the previous test
  511. # [15:35] <jgraham> Lachy: I still don't understand what you're trying to show
  512. # [15:35] <Lachy> Philip`, if you know of another lossless codec that is supported by an available tool, which will then allow me to reencode as dirac and theora, let me know
  513. # [15:36] <Lachy> jgraham, I'm trying to test the quality differences primarily between dirac and theora
  514. # [15:36] <jgraham> The absolute quality difference?
  515. # [15:37] <Lachy> what do you mean by the absolute quality difference?
  516. # [15:37] <jgraham> Well I don't really mean "absolute"
  517. # [15:37] <jgraham> I mean you seem to want perfect input
  518. # [15:38] <Philip`> Lachy: I think my point is that "lossless" is kind of meaningless, since almost any processing of video loses at least a little bit of data (even if it's just converting colour formats), though I'm not sure it's a particularly interesting or relevant point
  519. # [15:38] <jgraham> And then will presumably fix something (bitrate? encoding time?) for output
  520. # [15:38] <Lachy> yes, so that the only thing being tested is the codec quality, and so that any artifacts in the video are purely as a result of the final encode, rather than any previous step
  521. # [15:39] <Lachy> jgraham, yes, I will eliminate as many variables as physically possible
  522. # [15:39] <jgraham> OK but that seems irrelevent to video on the web
  523. # [15:39] <jgraham> I suspect it will show you that dirac is no good at small file sizes compared with theora and H.264 is better than both
  524. # [15:40] <jgraham> At large file sizes Dirac will be good
  525. # [15:40] <Philip`> From what I've heard, Dirac is currently aimed mainly at very-high-bitrate applications, so it wouldn't be very interesting to compare at low YouTube-style bitrates
  526. # [15:40] <jgraham> What Philip` said
  527. # [15:41] <takkaria> has anyone watched hi-def stuff on youtube? :)
  528. # [15:42] <Philip`> takkaria: I've tried, but Flash uses up all my CPU juice and it goes all jittery :-(
  529. # [15:42] <Philip`> (mplayer is perfectly happy with fullscreen 720p, though)
  530. # [15:43] <takkaria> I've uploaded a couple of hi-def videos to youtube, so it seems like Dirac might be suitable for that
  531. # [15:43] <jgraham> (As Philip` or someone said the right test for video-on-the-web is to take multiple types of real world (i.e. lossy) input, reencode it to H.264/Theora/Dirac in a way that takes roughly the same time as youtube and produces roughly the same file sizes as youtube, and compare the resulting output)
  532. # [15:45] * Joins: jacobrask (n=jacobr@vemod.brg.sgsnet.se)
  533. # [15:45] * jacobrask is now known as Creap
  534. # [15:45] * Philip` sees http://lwn.net/Articles/326830/ saying "If you are archiving video, building a unencumbered-bluray, or squeezing production grade 1080 HD video into 270mbit SD channels, Dirac is what you want. If you are webcasting with under a couple of megabits per second, Theora is what you want"
  535. # [15:46] <Philip`> though I'm not sure how much that's justified by data, or where the balancing point would be
  536. # [15:46] <Lachy> testing with lossy input makes it harder to compare the result, since so many of the artifacts in the output will be a direct result of the input, rather than the re-encoding process
  537. # [15:48] <Philip`> A hard-to-compare result sounds better than a result that's meaningless to anyone who wants to use the codecs in practice
  538. # [15:48] <jgraham> Lachy: Since the real world input is ally lossily encoded trying to remove that from the tests makes the tests less relevent
  539. # [15:48] <Lachy> if you take a look at the input avi file used in http://people.xiph.org/~greg/video/ytcompare/comparison.html it's incredibly lossy, which isn't useful
  540. # [15:48] <Lachy> well, I disagree with both of you
  541. # [15:49] <jgraham> Lachy: It depends what you are looking at. But if you are interested in video on the web you need to look at the type of source material that people actually use for video on the web
  542. # [15:50] <jgraham> Losslessly encoded sources are only one (rather rare) type of source material
  543. # [15:51] <Lachy> so, I'm only interested in the quality of the final encodes, since the results of encoding a lossless input to multiple encodings should show the same relative differences in output quality, as would a lossy input, but make it much clearer to judge the result
  544. # [15:52] <jgraham> That seems like a huge and, I think, provably false, assumption
  545. # [15:52] <Philip`> Are you assuming the quality of the output is directly proportional to the quality of the input?
  546. # [15:53] <jgraham> (e.g. if the lossly initial encoding is compresses in blocks then a lossy subsequent encoding that works with the same block size will look better than one that uses a totally different compression scheme, or has the blocks offset or something)
  547. # [15:53] <jgraham> s/l//
  548. # [15:54] <jgraham> (even if the other encoding scheme is "better" given ideal input)
  549. # [15:55] <Lachy> right, so if my input video used a lossy codec which unfairly favoured one of the output codecs due to block sizes or whatever, then the test would be biased.
  550. # [15:55] <Philip`> It seems like saying that if you have e.g. a lossless PDF document full of text and compress it as PNG and JPEG then PNG will do pretty well, and asserting that if you print out the PDF and take a photograph so you've got a lossy version then PNG will be relatively just as effective as before
  551. # [15:56] <Lachy> Philip`, yeah, that['s true
  552. # [15:56] <jgraham> Lachy: Which is why the interesting test is to look at the actual inputs that people use.
  553. # [15:58] <Lachy> that may also be interesting, but that doesn't mean what I want to do isn't
  554. # [15:59] * Quits: taf2_ (n=taf2@static-71-127-149-10.bltmmd.fios.verizon.net)
  555. # [15:59] <jgraham> Right, it's just not interesting for the video-on-the-web problem (except the tiny fraction of the problem that involves losslessly encoded input)
  556. # [16:00] <Philip`> (Actually the tinier fraction that involves losslessly encoded input with the same kind of colour range and detail and motion as the one you're testing with)
  557. # [16:01] * Philip` has noticed that iPlayer programmes with bright primary red/blue backgrounds tend to look terrible and blocky around the edges of the foreground, and wonders if that's an artifact of H.264 or something else
  558. # [16:04] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  559. # [16:05] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 54 (Connection reset by peer))
  560. # [16:05] * Joins: mpt_ (n=mpt@canonical/launchpad/mpt)
  561. # [16:06] <jgraham> takkaria: You got an email address you prefer?
  562. # [16:07] <Philip`> http://etill.net/projects/dirac_theora_evaluation/
  563. # [16:12] * Quits: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se) ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
  564. # [16:16] <takkaria> jgraham: andi@takkaria.org
  565. # [16:18] <hsivonen> interesting that Vorbis is missing in the BBC action even though it works today and BBC is interested in RF codecs
  566. # [16:18] <hsivonen> enough to put money into Dirac
  567. # [16:20] <Philip`> As far as I'm aware, it doesn't work in the sense that you could serve it over the web and most people would be able to listen to it without installing any new software
  568. # [16:20] <hsivonen> Philip`: that doesn't mention Thusnelda, which suggest the test may have used a stale encoder
  569. # [16:21] <Philip`> hsivonen: That seems quite likely (and apparently the tests were performed "Q2-2008")
  570. # [16:22] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  571. # [16:27] * Joins: ap (n=ap@70-1-233-65.pools.spcsdns.net)
  572. # [16:27] * Joins: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se)
  573. # [16:33] <takkaria> jgraham: any particular reason?
  574. # [16:37] <jgraham> takkaria: I used your @opera email address instead
  575. # [16:38] <jgraham> If you didn't get an email, I got it wrong :)
  576. # [16:39] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  577. # [16:39] * Parts: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  578. # [16:48] * Quits: Creap (n=jacobr@vemod.brg.sgsnet.se)
  579. # [16:55] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  580. # [16:57] * Joins: aroben (n=aroben@unaffiliated/aroben)
  581. # [17:01] * Joins: dglazkov (n=dglazkov@nat/google/x-fc77c64780d6d73f)
  582. # [17:03] * Joins: billmason (n=billmaso@ip179.unival.com)
  583. # [17:06] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  584. # [17:16] * Quits: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
  585. # [17:22] * Joins: remysharp (n=remyshar@vinov2.gotadsl.co.uk)
  586. # [17:23] <remysharp> hi, I'm having some trouble understanding the effectAllowed and dropEffect attribs in drag and drop - can anyone give me a helping hand for a min?
  587. # [17:24] * Quits: Khazou (n=Khazou@AReims-152-1-151-72.w90-7.abo.wanadoo.fr)
  588. # [17:31] <remysharp> okay - is dropEffect effect supposed to be on the dragged element or on the element we're dropping on to?
  589. # [17:31] <remysharp> it looks like (in the browser) that I'm supposed to use effectAllowed on the dragged element
  590. # [17:31] * Joins: starjive (i=beos@213-66-216-93-no30.tbcn.telia.com)
  591. # [17:31] <remysharp> but I don't understand the language used on the attributes then.... -
  592. # [17:32] * remysharp confused :-\
  593. # [17:36] * Joins: jacobolus (n=jacobolu@c-76-102-55-224.hsd1.ca.comcast.net)
  594. # [17:42] * Joins: taf2_ (n=taf2@static-71-127-149-10.bltmmd.fios.verizon.net)
  595. # [17:42] * Joins: Maurice (n=copyman@5ED548D4.cable.ziggo.nl)
  596. # [17:49] * Quits: pmuellr (n=pmuellr@nat/ibm/x-5665b245ef06aa54) (Read error: 110 (Connection timed out))
  597. # [17:49] * Joins: maikmerten (n=maikmert@Z9889.z.pppool.de)
  598. # [17:51] * Joins: pmuellr (n=pmuellr@nat/ibm/x-ac14aec4d44611af)
  599. # [17:51] * Quits: gsnedders (n=gsnedder@pat.se.opera.com) (Read error: 110 (Connection timed out))
  600. # [17:54] * Joins: poe (n=poe@unaffiliated/xerox)
  601. # [18:01] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  602. # [18:02] * Quits: remysharp (n=remyshar@vinov2.gotadsl.co.uk) ("Gotta shoot - peeyaow!")
  603. # [18:04] * Quits: poe (n=poe@unaffiliated/xerox) ("Quit")
  604. # [18:15] * Joins: myakura (n=myakura@p3126-ipbf1106marunouchi.tokyo.ocn.ne.jp)
  605. # [18:21] * Joins: gsnedders (n=gsnedder@c83-252-197-150.bredband.comhem.se)
  606. # [18:22] * Joins: slightlyoff (n=slightly@204.14.154.228)
  607. # [18:24] <gsnedders> ezyang: Habari will probably use it soon
  608. # [18:25] * Quits: dglazkov (n=dglazkov@nat/google/x-fc77c64780d6d73f) (Read error: 110 (Connection timed out))
  609. # [18:28] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-0c6c0196add77226)
  610. # [18:32] * Joins: slightlyoff__ (n=slightly@67.218.102.238)
  611. # [18:32] * Joins: dglazkov (n=dglazkov@nat/google/x-1d639b5dc80121f6)
  612. # [18:35] <ezyang> Nice! Once I fix the DOM issues, HTML Purifier 5.0 will also use html5lib
  613. # [18:38] * Quits: ttepass- (n=ttepas--@p5B014DF3.dip.t-dialin.net) ("?Q")
  614. # [18:38] * Quits: slightlyoff_ (n=slightly@72.14.224.1) (Read error: 110 (Connection timed out))
  615. # [18:38] * Joins: ttepasse (n=ttepas--@p5B014DF3.dip.t-dialin.net)
  616. # [18:39] * Joins: sypasche (n=sypasche@dhcp-83-219-111-101.customers.tvtnet.ch)
  617. # [18:39] * Quits: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se) ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
  618. # [18:40] * Quits: slightlyoff (n=slightly@204.14.154.228) (Success)
  619. # [18:40] * slightlyoff__ is now known as slightlyoff
  620. # [18:40] * Joins: jianli (n=jianli@72.14.227.1)
  621. # [18:41] <sypasche> Hixie: ping
  622. # [18:43] * sypasche is now known as syp
  623. # [18:46] * Quits: nessy (n=nessy@124-168-240-72.dyn.iinet.net.au) ("This computer has gone to sleep")
  624. # [18:47] * Parts: beowulf (i=wiglaf@ps4552.dreamhost.com)
  625. # [18:47] * Joins: jacobrask (n=jacobr@vemod.brg.sgsnet.se)
  626. # [18:47] * Quits: mpt_ (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  627. # [18:48] * jacobrask is now known as Creap
  628. # [18:48] * Quits: Creap (n=jacobr@vemod.brg.sgsnet.se) (Client Quit)
  629. # [18:50] * Joins: sbublava_ (n=stephan@77.116.227.26.wireless.dyn.drei.com)
  630. # [18:53] * Quits: ap (n=ap@70-1-233-65.pools.spcsdns.net)
  631. # [18:54] * Joins: jennb (n=jennb@72.14.227.1)
  632. # [18:54] * Joins: yshin (n=yshin@72.14.227.1)
  633. # [19:01] * Joins: nessy (n=nessy@124-168-240-72.dyn.iinet.net.au)
  634. # [19:02] * Quits: sbublava (n=stephan@77.119.142.2.wireless.dyn.drei.com) (Read error: 110 (Connection timed out))
  635. # [19:06] * Joins: atwilson (n=atwilson@74.125.59.1)
  636. # [19:16] * Joins: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se)
  637. # [19:17] * Quits: dglazkov (n=dglazkov@nat/google/x-1d639b5dc80121f6) (Remote closed the connection)
  638. # [19:17] * Joins: dglazkov (n=dglazkov@nat/google/x-4a7fe27785c06a26)
  639. # [19:18] * Joins: jianli_ (n=jianli@72.14.227.1)
  640. # [19:19] * Quits: jianli_ (n=jianli@72.14.227.1) (Read error: 54 (Connection reset by peer))
  641. # [19:19] * Joins: jianli_ (n=jianli@72.14.227.1)
  642. # [19:19] * Quits: slightlyoff (n=slightly@67.218.102.238)
  643. # [19:20] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
  644. # [19:21] * Joins: cying (n=cying@70.90.171.153)
  645. # [19:22] * Quits: nessy (n=nessy@124-168-240-72.dyn.iinet.net.au) ("This computer has gone to sleep")
  646. # [19:23] * Joins: sayrer__ (n=chatzill@user-0cceh2r.cable.mindspring.com)
  647. # [19:23] * Joins: slightlyoff (n=slightly@nat/google/x-904447a9192f84fe)
  648. # [19:28] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  649. # [19:28] * Quits: sbublava_ (n=stephan@77.116.227.26.wireless.dyn.drei.com)
  650. # [19:35] * Quits: jianli (n=jianli@72.14.227.1) (Read error: 110 (Connection timed out))
  651. # [19:42] * Quits: jianli_ (n=jianli@72.14.227.1)
  652. # [19:43] * Joins: jianli (n=jianli@72.14.227.1)
  653. # [19:45] * Joins: dimich (n=dimich@72.14.227.1)
  654. # [20:41] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  655. # [20:41] * Quits: jianli (n=jianli@72.14.227.1)
  656. # [20:42] * Joins: jianli (n=jianli@72.14.227.1)
  657. # [20:43] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  658. # [20:45] * Quits: gsnedders (n=gsnedder@c83-252-197-150.bredband.comhem.se) (Remote closed the connection)
  659. # [20:45] * Joins: gsnedders (n=gsnedder@c83-252-197-150.bredband.comhem.se)
  660. # [20:45] * Quits: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  661. # [20:50] * Joins: dolske (n=dolske@nat/mozilla/x-64178f12f2b80384)
  662. # [20:52] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  663. # [20:53] * Quits: myakura (n=myakura@p3126-ipbf1106marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  664. # [20:55] * Quits: syp (n=sypasche@dhcp-83-219-111-101.customers.tvtnet.ch) ("Leaving.")
  665. # [20:59] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  666. # [21:01] * aboodman2 is now known as aboodman
  667. # [21:03] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  668. # [21:07] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  669. # [21:10] * Joins: dbaron (n=dbaron@nat/mozilla/x-f721f4ad2fbdb03d)
  670. # [21:13] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-0c6c0196add77226)
  671. # [21:16] * Parts: michaeln (n=michaeln@nat/google/x-649e08c808713584)
  672. # [21:16] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  673. # [21:24] * Quits: taf2_ (n=taf2@static-71-127-149-10.bltmmd.fios.verizon.net)
  674. # [21:28] * Joins: mpt_ (n=mpt@canonical/launchpad/mpt)
  675. # [21:33] * Joins: jwalden (n=waldo@nat/mozilla/x-b67b2f6533757efb)
  676. # [21:38] * Quits: excrypf (n=nogah@118.71.77.84) ("Leaving.")
  677. # [21:41] * Quits: archtech (n=stanv@83.228.56.37)
  678. # [22:00] * Joins: weinig (n=weinig@17.246.17.208)
  679. # [22:09] * Joins: othermaciej (n=mjs@17.246.18.9)
  680. # [22:14] * Quits: campd_ (n=dave@li5-166.members.linode.com) (Remote closed the connection)
  681. # [22:16] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-094e799f06deb7df)
  682. # [22:19] * Quits: pmuellr (n=pmuellr@nat/ibm/x-ac14aec4d44611af)
  683. # [22:24] * Joins: michaeln (n=michaeln@nat/google/x-d7805bcbc47d8c8e)
  684. # [22:34] * Quits: weinig (n=weinig@17.246.17.208)
  685. # [22:40] * Quits: gsnedders (n=gsnedder@c83-252-197-150.bredband.comhem.se)
  686. # [22:40] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  687. # [22:51] * Joins: Sirisian (n=Sirisian@ppp-70-226-91-20.dsl.klmzmi.ameritech.net)
  688. # [23:01] * Quits: mpt_ (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  689. # [23:05] * Joins: weinig (n=weinig@17.246.17.208)
  690. # [23:13] * Quits: weinig (n=weinig@17.246.17.208)
  691. # [23:14] * Quits: zdobersek (n=zan@cpe-92-37-74-10.dynamic.amis.net) ("Leaving.")
  692. # [23:17] * Quits: maikmerten (n=maikmert@Z9889.z.pppool.de) (Remote closed the connection)
  693. # [23:30] * Joins: ttepass- (n=ttepas--@p5B017EDD.dip.t-dialin.net)
  694. # [23:31] * Joins: weinig (n=weinig@17.246.17.208)
  695. # [23:31] * Joins: archtech (n=stanv@83.228.56.37)
  696. # [23:38] * Joins: ojan (n=ojan@72.14.229.81)
  697. # [23:42] * Joins: poe (n=poe@unaffiliated/xerox)
  698. # [23:43] * Joins: ap (n=ap@17.246.19.81)
  699. # [23:44] * Quits: ap (n=ap@17.246.19.81) (Remote closed the connection)
  700. # [23:45] * Parts: billmason (n=billmaso@ip179.unival.com)
  701. # [23:45] * Joins: ap (n=ap@nat/apple/x-310fc59502afba19)
  702. # [23:45] * Quits: Maurice (n=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  703. # [23:46] * Quits: Phae (n=phaeness@cpc2-acto6-0-0-cust747.brnt.cable.ntl.com)
  704. # [23:49] * Quits: ttepasse (n=ttepas--@p5B014DF3.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  705. # Session Close: Sat Jul 11 00:00:00 2009

The end :)