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

Options:

  1. # Session Start: Sat May 12 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:00] <Philip`> To find the colour of a pixel, like with the colour-picker tool in a paint program
  4. # [00:01] <Hixie> for that case you can just use the first pixel
  5. # [00:01] <Hixie> where's the problem?
  6. # [00:01] <Philip`> As far as I understand it, it could return zero pixels of data
  7. # [00:01] <Hixie> why?
  8. # [00:01] <othermaciej> Philip`: it could only be zero if you have a < 1 scale factor
  9. # [00:02] <hsivonen> hmm. three XTech timeslots where I find it hard to decide which session to attend...
  10. # [00:02] <Philip`> Does anything prevent there being a < 1 scale factor?
  11. # [00:02] <othermaciej> Philip`: I think with non-integer scale factors of the backing store, implementing the requirement that putImageData(getImageData()) be idempotent is extremely difficult
  12. # [00:02] * Joins: weinig (n=weinig@m810f36d0.tmodns.net)
  13. # [00:02] <Hixie> surely it's just a matter of rounding the same way?
  14. # [00:04] * othermaciej thinks
  15. # [00:05] <othermaciej> maybe that part is not hard; more that doing a putImageData() at a different location of the same data could have odd-looking results
  16. # [00:05] <othermaciej> you could get cracks where you expected things to line up seamlessly
  17. # [00:05] <Hixie> yup, but if you want to move data, you should use drawImage()
  18. # [00:06] <Hixie> gID and pID really are only for two use cases, applying filters, and the colour picker -- for the colour picker case maybe i should make the spec guarentee that h*w >= 1
  19. # [00:08] * Quits: timblair (n=timblair@host-87-74-129-183.bulldogdsl.com)
  20. # [00:11] * Quits: weinig (n=weinig@m810f36d0.tmodns.net)
  21. # [00:11] <zcorpan> perfect! now i know how we should make the spec easier to read! http://venturebeat.com/2007/05/10/live-ink-offers-better-way-to-read-text-online/
  22. # [00:12] <Philip`> For filters that need to know the device scale factor (Gaussians etc), I suppose you could estimate it by dividing the returned .width and the parameter sw, at least for large enough areas that you won't get rounding problems - I don't know whether it'd be worth having ImageData explicitly tell you the scale factor
  23. # [00:12] * Parts: billmason (n=billmaso@ip156.unival.com)
  24. # [00:13] <Hixie> zcorpan: you want me to turn the spec into one long poem? :-)
  25. # [00:14] <zcorpan> yeah :)
  26. # [00:14] <zcorpan> it would turn it into 1500 pages in print
  27. # [00:15] <hsivonen> zcorpan: they aren't eating their own dogfood for their paper
  28. # [00:15] * Joins: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  29. # [00:16] <zcorpan> http://www.accessifyforum.com/viewtopic.php?p=52490#52490
  30. # [00:41] * Quits: YaaL (i=yaal@hell.pl) (Remote closed the connection)
  31. # [00:41] * Joins: YaaL (i=yaal@hell.pl)
  32. # [00:45] * Quits: kingryan (n=kingryan@142.131.37.98) (Read error: 110 (Connection timed out))
  33. # [00:48] <hsivonen> http://en.wikipedia.org/w/index.php?title=Web_Hypertext_Application_Technology_Working_Group&curid=1789925&diff=125647714&oldid=123198165
  34. # [00:48] <Hixie> heh
  35. # [00:48] <Hixie> that's news to me
  36. # [00:49] <Dashiva> Well, they wouldn't be very undercover if they told you
  37. # [00:49] <Hixie> that page has so many errors
  38. # [00:49] <Hixie> anyway
  39. # [00:50] <othermaciej> but it's Truthy!
  40. # [00:50] <hsivonen> reverted
  41. # [00:51] <Hixie> the version of reality before you reverted was better
  42. # [00:52] <Dashiva> We need a quantum wikipedia, which alters reality to the truth you edit into it
  43. # [00:52] <hsivonen> Hixie: how so?
  44. # [00:52] <Hixie> that would be really freaking dangerous
  45. # [00:52] <Hixie> hsivonen: if microsoft actually were involved, it would be awesome
  46. # [00:53] * Joins: kingryan (n=kingryan@banff-72-29-239-177.mycanopy.net)
  47. # [00:53] <Hixie> (in the whatwg, i mean)
  48. # [00:53] <hsivonen> I see
  49. # [00:54] <zcorpan> data: [i for (i in function (n) { for (let i = 0; i < n; i += 1) yield 0 }(w*h*4)) ]
  50. # [00:55] * zcorpan dosn't recognize that syntax :|
  51. # [00:55] <Hixie> js 1.7
  52. # [00:55] <Dashiva> also known as pythonscript
  53. # [00:55] <bewest> ooOoooo
  54. # [00:55] <Philip`> http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
  55. # [00:55] <Hixie> (works in fx2)
  56. # [00:57] <zcorpan> i get "Error: missing ; after for-loop initializer"
  57. # [00:57] <dbaron> there should *really* be a simpler way to do that
  58. # [00:58] <Philip`> It'd be better if they copied more of Python and let you write "[0] * (w*h*4)"
  59. # [00:59] <Hixie> zcorpan: make sure you say <script type="text/javascript;version=1.7">
  60. # [01:00] <zcorpan> ah
  61. # [01:00] <zcorpan> ok
  62. # [01:03] <zcorpan> Hixie: "There's still no way to _get_ the transformation matrix, but you can not _set_ the transformation matrix now, which should be of help here." did you mean s/not // ?
  63. # [01:04] <Hixie> i meant "now"
  64. # [01:04] <Hixie> oops
  65. # [01:04] <Hixie> always get those mixed up
  66. # [01:05] <zcorpan> that's what you get for using dvorak :P
  67. # [01:05] <Hixie> hehe
  68. # [01:05] <Hixie> actually i get them confused in qwerty too
  69. # [01:05] <Hixie> i think it's a brain thing
  70. # [01:05] <Hixie> not a finger thing
  71. # [01:06] <zcorpan> oh
  72. # [01:06] <Hixie> i notice a lot of other people doing it too
  73. # [01:06] <dbaron> is one of them me?
  74. # [01:07] <Hixie> dunno
  75. # [01:07] <Hixie> maybe :-)
  76. # [01:09] <Hixie> 24 <canvas> mails left
  77. # [01:09] <Hixie> (not counting text issues)
  78. # [01:13] * othermaciej is now known as om_coffee
  79. # [01:22] * Parts: zcorpan (n=zcorpan@84-216-40-21.sprayadsl.telenor.se)
  80. # [01:23] * Joins: zcorpan (n=zcorpan@84-216-40-21.sprayadsl.telenor.se)
  81. # [01:24] * om_coffee is now known as othermaciej
  82. # [01:28] * Quits: yod (n=ot@banff-72-29-239-177.mycanopy.net) ("Leaving")
  83. # [01:33] * Quits: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  84. # [01:35] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  85. # [01:51] * Quits: kingryan (n=kingryan@banff-72-29-239-177.mycanopy.net)
  86. # [01:59] * Joins: kingryan (n=kingryan@142.131.37.98)
  87. # [02:04] * Quits: gavin (n=gavin@firefox/developer/gavin) (Remote closed the connection)
  88. # [02:04] * Joins: gavin (n=gavin@people.mozilla.com)
  89. # [02:16] * Joins: aroben_ (n=adamrobe@17.203.15.208)
  90. # [02:16] * Quits: aroben_ (n=adamrobe@17.203.15.208) (Remote closed the connection)
  91. # [02:36] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  92. # [02:54] * Quits: othermaciej (i=mjs@nat/apple/x-c438fb3298c4fb7a)
  93. # [03:27] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  94. # [03:31] * Joins: weinig (n=weinig@m810f36d0.tmodns.net)
  95. # [03:44] * Joins: kingryan_ (n=kingryan@142.131.37.98)
  96. # [03:44] * Quits: kingryan (n=kingryan@142.131.37.98) (Read error: 104 (Connection reset by peer))
  97. # [03:46] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  98. # [04:05] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  99. # [04:07] * Joins: markp (n=mark@adsl-221-79-235.rmo.bellsouth.net)
  100. # [04:09] * Quits: zcorpan (n=zcorpan@84-216-40-21.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  101. # [04:33] * weinig is now known as weinig|food
  102. # [04:33] * Quits: weinig|food (n=weinig@m810f36d0.tmodns.net)
  103. # [04:50] * Quits: markp (n=mark@adsl-221-79-235.rmo.bellsouth.net) (Read error: 113 (No route to host))
  104. # [04:53] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  105. # [04:58] * kingryan_ is now known as kingryan
  106. # [05:12] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  107. # [05:18] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  108. # [05:18] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  109. # [05:19] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  110. # [05:22] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  111. # [05:22] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  112. # [05:22] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  113. # [05:25] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  114. # [05:26] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  115. # [05:28] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  116. # [05:28] * Quits: kingryan (n=kingryan@142.131.37.98)
  117. # [05:29] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  118. # [05:32] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  119. # [05:32] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  120. # [05:45] * Quits: tantek (n=tantek@corp.technorati.com)
  121. # [05:46] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  122. # [05:47] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  123. # [05:47] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  124. # [05:48] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  125. # [05:48] * Parts: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  126. # [05:48] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  127. # [05:49] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  128. # [05:52] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  129. # [05:52] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  130. # [05:53] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  131. # [05:53] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  132. # [05:55] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  133. # [05:55] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  134. # [05:55] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  135. # [05:56] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  136. # [05:56] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  137. # [05:56] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  138. # [05:57] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  139. # [05:57] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  140. # [05:58] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  141. # [05:58] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  142. # [05:59] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  143. # [05:59] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  144. # [06:00] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  145. # [06:00] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  146. # [06:01] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  147. # [06:01] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  148. # [06:01] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  149. # [06:05] * aroben_ is now known as aroben
  150. # [06:16] * Quits: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  151. # [06:36] * Joins: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net)
  152. # [06:54] * Quits: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/0000000000]")
  153. # [06:54] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  154. # [07:03] * Joins: wakaba_ (n=w@118.166.210.220.dy.bbexcite.jp)
  155. # [07:20] * Quits: wakaba (n=w@118.166.210.220.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
  156. # [07:47] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  157. # [08:02] * Joins: KevinMarks (n=Snak@h-68-164-93-9.snvacaid.dynamic.covad.net)
  158. # [08:38] * Quits: dolphinling (n=chatzill@rbpool4-60.shoreham.net) ("upgrading chatzilla")
  159. # [08:42] * Joins: dolphinling (n=chatzill@rbpool4-60.shoreham.net)
  160. # [09:22] * Joins: ROBOd (n=robod@86.34.246.154)
  161. # [09:30] <annevk> Hixie, what would be nice if .fillStyle returned a four-digit array instead
  162. # [09:31] <annevk> and the same for .strokeStyle
  163. # [09:31] <annevk> that would be much more trivial to parse
  164. # [09:31] <Hixie> it would also make it impossible to do .fillStyle = .fillStyle
  165. # [09:32] <Hixie> unless we added yet another way of assigning colour
  166. # [09:32] <Hixie> but anyway, who the heck is parsing these colours
  167. # [09:32] <Hixie> you had to set them yourself
  168. # [09:32] <Hixie> you KNOW what the colour is
  169. # [09:39] * Joins: timblair (n=timblair@host-87-74-129-183.bulldogdsl.com)
  170. # [09:41] <annevk> people parse it
  171. # [09:41] <annevk> apparently
  172. # [09:41] <annevk> and yes, it would mean assigning would have to accept a four-digit array
  173. # [09:43] * Quits: timblair (n=timblair@host-87-74-129-183.bulldogdsl.com) (Client Quit)
  174. # [09:44] <annevk> I guess I raised some problems multiple times because I don't keep track of the e-mails I have already sent
  175. # [10:01] <Hixie> :-)
  176. # [10:01] <Hixie> i wasn't criticising
  177. # [10:01] <Hixie> just thought it was amusing :-)
  178. # [10:02] <annevk> btw, as for dropping features, did anyone implement shadows already?
  179. # [10:13] <Hixie> safari, i assume
  180. # [10:13] <Hixie> that was in their initial description
  181. # [10:13] <annevk> oh ok
  182. # [10:14] * Quits: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net) ("g'night")
  183. # [10:18] <othermaciej> we do shadows?
  184. # [10:18] <othermaciej> cool
  185. # [10:18] <Hixie> i haven't tested it
  186. # [10:18] <Hixie> at l0east not recently
  187. # [10:19] <annevk> heh
  188. # [10:20] <annevk> the primary use case for having totally global id= is getting the requirement for xml:id out of SVG
  189. # [10:20] <Hixie> why?
  190. # [10:20] <Hixie> svg already has id=""
  191. # [10:20] <Hixie> it only uses xml:id in svg 1.2, no? and svg 1.2 is a waste of time anyway.
  192. # [10:21] <othermaciej> svg added xml:id on the theory that it would be play nicer with embedding markup in other languages
  193. # [10:21] <othermaciej> (apparently xhtml 1.0 and xhtml 1.1 were not considered among the important languages to embed)
  194. # [10:21] <othermaciej> does MathML have any attributes of type ID?
  195. # [10:21] <othermaciej> RSS? Atom?
  196. # [10:21] <annevk> SVG Tiny 1.2 is happing at least for Opera
  197. # [10:21] <hsivonen> the way SVG 1.2 specs IDness assignment is crazy
  198. # [10:21] * annevk doesn't have time to do SVG fights atm
  199. # [10:22] <hsivonen> can be please get it repealed somehow?
  200. # [10:22] <Hixie> annevk: sorry to hear that
  201. # [10:22] <othermaciej> we probably won't implement SVG 1.2 in WebKit, maybe selected parts, but likely not the whole thing
  202. # [10:22] * annevk isn't sure about SVG 1.2 though
  203. # [10:22] <Hixie> annevk: who's doing the qa?
  204. # [10:23] <annevk> not sure
  205. # [10:25] <annevk> Seems Acid3 has some script issues btw which causes it not to run
  206. # [10:25] <hsivonen> it would be nice to have a spec for the subset of SVG that Opera, Apple and Mozilla implement
  207. # [10:26] <annevk> That would be a tutorial
  208. # [10:26] <hsivonen> annevk: I mean SVG5
  209. # [10:27] <hsivonen> annevk: something realistic you could check conformance against
  210. # [10:27] <hsivonen> annevk: If I support SVG 1.1 but browsers support pieces of SVG 1.2, those pieces get flagged
  211. # [10:28] <annevk> Someone just has to free up his time for the foreseeable future and do it... I suppose
  212. # [10:28] <hsivonen> annevk: If I supported SVG 1.2, I'd fail to flag stuff that authors should avoid
  213. # [10:28] * annevk doesn't know much about vector graphics and doesn't have much free time
  214. # [10:31] <Hixie> acid3 isn't ready yet
  215. # [10:32] * Joins: maikmerten (n=maikmert@L82a0.l.pppool.de)
  216. # [10:33] <annevk> maikmerten, hi, Opera's implementation of <video> is experimental
  217. # [10:34] <maikmerten> annevk, yup
  218. # [10:34] <annevk> as such, we don't support all members of HTMLMediaElement
  219. # [10:34] <maikmerten> yeah, only a basic subset
  220. # [10:35] <maikmerten> I expected nothing else - doing a full scale implementation only makes sense once the <video> part of the spec is considered stable
  221. # [10:36] <annevk> Our submission along with the work from Apple actually made Hixie draft that part of the spec as I understand it
  222. # [10:36] <maikmerten> annevk, by the way, any plans to expose the Theora postprocessing options in Opera?
  223. # [10:36] <Hixie> that could be a problem, since it won't be stable until there are at least two implementations :-)
  224. # [10:36] <annevk> And it basically consisted of .play() .pause() and .stop() if I remember correctly
  225. # [10:37] <maikmerten> I did write howcome and told him about the new Theora code (improved encoder, complete and safe decoder) but I guess that the mail was eaten by a spam filter ;)
  226. # [10:37] <maikmerten> yeah, and stop() more or less vanished, so it seems
  227. # [10:37] <annevk> I believe .stop() is not part of the specification, not sure
  228. # [10:37] <annevk> right
  229. # [10:37] <annevk> oh, also in the implementation?
  230. # [10:37] <maikmerten> nope
  231. # [10:37] <maikmerten> the experimental build has stop()
  232. # [10:38] <maikmerten> after finding out that the spec only has pause() the wikimedia player was altered to honor this
  233. # [10:38] <annevk> ah ok
  234. # [10:39] <annevk> if you guys would like a bit more than play() and pause() I suppose you could post that somewhere and I'll see what I can do
  235. # [10:39] <maikmerten> well, a stop() would be cool ;) - but that can be mimicked with pause() and start set to zero, I guess
  236. # [10:40] <annevk> Hixie, any reason there's no stop()?
  237. # [10:40] <Hixie> what would it do?
  238. # [10:40] <maikmerten> stop playback and set the playback position to zero
  239. # [10:40] <maikmerten> (which can be achieved with the current draft in two steps already.... so...)
  240. # [10:40] <Hixie> ah. then there is. it's just spelt a bit longer: m.pause(); m.duration = 0;
  241. # [10:40] <annevk> (Although what I meant was features missing in Opera.)
  242. # [10:41] <annevk> you actually mean the more horrible currentTime
  243. # [10:41] <Hixie> right
  244. # [10:41] <Hixie> m.pause(); m.currentTime = 0;
  245. # [10:42] * annevk would like to have stop() back
  246. # [10:42] <annevk> It was also on Audio()
  247. # [10:43] <Hixie> if it did something that you couldn't otherwise do...
  248. # [10:43] <Hixie> i'm not a fan of adding shortcuts before we know if anyone will use them
  249. # [10:43] <maikmerten> oh, one thing: A reliable way to find out if <video> is supported would be nice. Currently I'm just embedding a <video> element without src, fetch that with getElementById and see if that has a play method
  250. # [10:44] <maikmerten> don't know if that is how it's supposed to be
  251. # [10:44] <maikmerten> and in the long term a way to query mime types supported by audio/video may be nice, too
  252. # [10:45] <Hixie> if (video.play) is one way to find out
  253. # [10:45] <Hixie> anyway, i'm off hame
  254. # [10:45] <Hixie> nn
  255. # [10:45] <annevk> g'night
  256. # [10:45] <maikmerten> night
  257. # [10:47] <annevk> Hixie, hmm, Wikipedia would use them :)
  258. # [10:48] <othermaciej> maikmerten: the intent is that you specify multiple sources with <source> elements instead of querying
  259. # [10:48] <maikmerten> as for the mime type querying: Sooner or later as codec development goes on user agents may pick up new codecs (on the free side Ogg Ghost + Ogg Dirac or whatever, on the other side the future MPEG codecs) and content providers may want to be able to see what's supported. Plus as Ogg is a SHOULD some implementations may not implement it and then the either a fallback should be able to kick in or just tell the user
  260. # [10:48] <maikmerten> ah, k
  261. # [10:48] <maikmerten> that's an even better solution that's scripting independent
  262. # [10:48] <othermaciej> maikmerten: video codec support also is in general more fine-grained than mime types
  263. # [10:48] <maikmerten> fair point
  264. # [10:49] <maikmerten> currently e.g. the Wikimedia player queries the mime types and if it finds application/ogg (VLC plugin, totem plugin) it just assumes that Ogg plugin will also support video
  265. # [10:49] <othermaciej> and the <source> element supports that via the MIME type codecs parameter
  266. # [10:49] <othermaciej> it would be hard for a plugin to report all combos of the codecs parameter it supports
  267. # [10:49] <maikmerten> true
  268. # [10:50] <maikmerten> <annevk> Hixie, hmm, Wikipedia would use them :) <-- well, Wikipedia will adapt to whatever is specified here, it shouldn't be the other way round
  269. # [10:51] <maikmerten> the fact it's already having experimental <video> support is more to give a real-life testing ground for implementations and to voice support for the idea
  270. # [10:51] * annevk was lobbying for less changes to Opera :)
  271. # [10:52] <annevk> but yeah
  272. # [10:52] <maikmerten> haha, right, standard procedure when several vendors come together... "Why not adapt to what we already have?" ;-)
  273. # [10:53] <maikmerten> I nominate <layer> ;)
  274. # [10:53] <hsivonen> I have now readjusted truthiness regarding the WHATWG and HTML5
  275. # [10:53] <hsivonen> on wikipedia, that is
  276. # [10:54] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  277. # [10:54] <maikmerten> I parse that as "I edited the whatwg article on wikipedia", correct?
  278. # [10:54] <hsivonen> maikmerten: and HTML5 and HTML
  279. # [10:54] <maikmerten> ah, nice
  280. # [10:55] <annevk> I like http://en.wikipedia.org/wiki/HTML5
  281. # [10:55] <annevk> "The HTML5 language is defined by a draft specification called “HTML 5” (note the space)."
  282. # [10:55] <hsivonen> maikmerten: the article was called truthy last night, because it had some bogus stuff in it
  283. # [10:55] <maikmerten> well, as usual ;)
  284. # [10:56] <maikmerten> (I *like* Wikipedia, but at times the strangest conceptions make it into articles because no real expert monitors them)
  285. # [10:56] <annevk> It's also hard to get some articles changed, like HTML
  286. # [10:57] <annevk> Although now HTML5 is done at the W3C it should be more easy I guess
  287. # [10:57] <hsivonen> annevk: I cited emails on lists.w3.org to avoid immediate reverts to the old accepted truth
  288. # [10:57] <maikmerten> (by the way: Is there a reliable way to see if Java is *working* apart from embedding an applet and seeing if JavaScript can interact with that?)
  289. # [10:58] <annevk> you might not have to embed it
  290. # [10:58] <annevk> you could create the elements (such as <video> simply through script)
  291. # [10:58] <annevk> and then do the check
  292. # [10:59] <annevk> video = document.createElement('video'); if(video.play) { etc. }
  293. # [11:01] <maikmerten> oh, sweet
  294. # [11:01] <maikmerten> my JavaScript skills sorta cover whatever came with Netscape 3.0 ;-)
  295. # [11:01] <annevk> nice
  296. # [11:01] <maikmerten> (and with "cover" I mean "I think I know 10% of that") ;)
  297. # [11:02] <maikmerten> time to educate myself on the DOM
  298. # [11:03] <othermaciej> hmm, the WHATWG article still mentions microsoft
  299. # [11:03] <othermaciej> http://en.wikipedia.org/wiki/Whatwg
  300. # [11:04] * Quits: marcosc (n=chatzill@131.181.148.226) ("...and I'm gone.")
  301. # [11:05] <hsivonen> othermaciej: but now accurately, I hope
  302. # [11:05] <annevk> othermaciej, what it says there is correct though, right?
  303. # [11:05] <othermaciej> what I see is "The key contributing groups in the WHATWG are Google, the Mozilla Foundation, Opera Software, Apple Inc. and Microsoft."
  304. # [11:05] <hsivonen> othermaciej: reload
  305. # [11:06] <hsivonen> othermaciej: I guess you have an old cached version
  306. # [11:06] <hsivonen> othermaciej: either in your caches or in wikipedia's
  307. # [11:06] <othermaciej> hsivonen: just did; perhaps I'm a victim of too aggressive caching somewhere
  308. # [11:07] <othermaciej> hsivonen: seems to be in my browser cache
  309. # [11:07] * Joins: auk_ (n=scott@h-69-3-183-68.lsanca54.dynamic.covad.net)
  310. # [11:08] * Quits: auk_ (n=scott@h-69-3-183-68.lsanca54.dynamic.covad.net) (Read error: 104 (Connection reset by peer))
  311. # [11:08] * annevk wonders why Wikipedia doesn't do redirects "better"
  312. # [11:09] <othermaciej> I wonder why the description of the WHATWG membership in the Discuss page for that article says "Maciej Stachowiak [ worked on Safari ]"
  313. # [11:09] <othermaciej> none of the others are in the past tense
  314. # [11:11] <annevk> dunno
  315. # [11:11] <maikmerten> I don't consider the discuss pages to be "canon" information
  316. # [11:12] <maikmerten> (wow, I just sounded like a Star Trek fan)
  317. # [11:12] <othermaciej> whoever wrote the post saying that was confused I think
  318. # [11:13] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  319. # [11:13] <othermaciej> damn, I screwed up the comment threading
  320. # [11:13] <othermaciej> maikmerten: is it considered bad form for someone closely associated with a product / project to edit the articles about it a lot?
  321. # [11:14] <maikmerten> othermaciej, good question - depends. Rule of thumb would say it's bad style
  322. # [11:14] <othermaciej> maikmerten: I really want to make a bunch of changes to the WebCore and WebKit articles (mainly merge most of the content into the WebKit one and change all the rendering engine list/comparison pages to point to WebKit instead of WebCore) but I'm worried this would be considered inappropriate
  323. # [11:15] <maikmerten> well, if the content is on a purely technical level I don't see why developers shouldn't be able to contribute
  324. # [11:15] <maikmerten> after all that is not the usual company propaganda thing that is controversial
  325. # [11:16] <maikmerten> err, semantics were wrong on the last sentence
  326. # [11:16] <othermaciej> I do have a lot of personal expert information which might not be based on published info
  327. # [11:16] <maikmerten> as long as it stays on a technical level it's okay, I'd guess. Problematic would be company propaganda
  328. # [11:16] <othermaciej> like what apps link to WebCore directly vs linking to WebKit
  329. # [11:17] <othermaciej> but that is easily verifiable
  330. # [11:17] <othermaciej> (at least for people who have access to the app)
  331. # [11:17] <maikmerten> oh, and disclaimer: I'm not part of the Wikipedia project, just assist a bit with video technology related stuff
  332. # [11:17] <annevk> Are you part of the Theora project?
  333. # [11:18] <maikmerten> well, yes and no. Not official member of xiph.org but I'm hanging around in the #theora channel and contributed a bit on the encoder
  334. # [11:18] <annevk> k
  335. # [11:19] <maikmerten> the border is a bit unclear as xiph.org isn't a real company but more a group of free media technology guys
  336. # [11:22] <maikmerten> (well, to be precise: It is a legal entity complete with a board etc. - but that doesn't mean you have to be "member" of some sort to contribute)
  337. # [11:44] * Quits: psa (n=yomode@posom.com) (Remote closed the connection)
  338. # [11:44] * Parts: annevk (n=annevk@pat-tdc.opera.com)
  339. # [11:49] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  340. # [11:55] * Joins: annevk (n=annevk@pat-tdc.opera.com)
  341. # [12:31] <Philip`> About accepting [r,g,b,a] as input to fillStyle/strokeStyle, that'd be kind of handy since normally I have to write a [r,g,b,a]-to-"rgba(...)" function every time I do anything with colours, and have to worry about silly things like r,g,b being 0-255 while a is 0-1. (Not exceptionally handy and maybe not worth the cost, though.)
  342. # [12:33] <annevk> is "a" in ImageData.data 0-225?
  343. # [12:33] <annevk> I think you should mention the above on the list
  344. # [12:33] <Philip`> It is
  345. # [12:33] <annevk> cool
  346. # [12:34] <annevk> currently it accepts CSS for ease of use, but if you actually need to convert to CSS first it's not really "easy" anymore and just adds to the processing cost
  347. # [12:35] <Philip`> It's possibly nice that you can do HSL the same way as RGB when it's through CSS, which would no longer be the same if you had [r,g,b(,a)] arrays, but I don't know if anybody actually wants to use HSL
  348. # [12:37] <annevk> you want ,a to be optional?
  349. # [12:37] <annevk> it would still accept CSS I think
  350. # [12:39] <Philip`> Is there any reason not to make it optional? People will want solid colours more than they want transparent colours, so it would seem nicer to simplify that case rather than requiring a redundant ',255' every time
  351. # [12:39] * Joins: nickshanks_ (n=nicholas@home.nickshanks.com)
  352. # [12:39] <othermaciej> maybe functions to make and parse color strings would be more useful
  353. # [12:39] <othermaciej> the array could only support a limited number of color formats
  354. # [12:40] <annevk> Philip`, fair enough
  355. # [12:40] <annevk> othermaciej, thought about that... yet more global methods?
  356. # [12:40] <othermaciej> but makeRGB, makeRGBA, makeHSL, makeHSLA, etc could do it
  357. # [12:40] <othermaciej> they don't necessarily need to be global
  358. # [12:40] <othermaciej> could be part of the CSSOM
  359. # [12:40] <othermaciej> method on CSSColorValue constructor maybe
  360. # [12:41] <annevk> that might work
  361. # [12:41] * annevk thought of having CSSColorValue.data[0,0,0,0] as opposed to .red, .green .blue and .alpha
  362. # [12:43] <othermaciej> .rgbaData might make more sense
  363. # [12:43] <othermaciej> but I'm not sure it is more clear than named properties
  364. # [12:44] <annevk> me neither
  365. # [12:47] * Quits: nickshanks (n=nicholas@home.nickshanks.com) (Read error: 110 (Connection timed out))
  366. # [12:49] * othermaciej is now known as om_sleep
  367. # [12:52] * Joins: ROBOd (n=robod@86.34.246.154)
  368. # [13:20] * Joins: zcorpan (n=zcorpan@84-216-42-169.sprayadsl.telenor.se)
  369. # [13:22] <annevk> nice Philip`
  370. # [13:44] * Joins: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  371. # [14:02] * Joins: zcorpan_ (n=zcorpan@84-216-43-239.sprayadsl.telenor.se)
  372. # [14:03] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  373. # [14:06] * Joins: markp (n=mark@adsl-221-79-235.rmo.bellsouth.net)
  374. # [14:08] * Quits: zcorpan (n=zcorpan@84-216-42-169.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  375. # [15:01] <hsivonen> cool. my HTML5 revisions to wikipedia are still standing after 4 hours
  376. # [15:03] <annevk> heh
  377. # [15:05] <annevk> ooh, those are pretty controversial
  378. # [15:06] * annevk had only seen the first
  379. # [15:17] <hsivonen> annevk: what's controversial?
  380. # [15:17] <hsivonen> annevk: I tried to stick to stating facts
  381. # [15:18] <annevk> controversial facts, if you wish
  382. # [15:18] * Joins: dev0 (i=Tobias@unaffiliated/icefox0)
  383. # [15:19] * Quits: markp (n=mark@adsl-221-79-235.rmo.bellsouth.net) (Read error: 110 (Connection timed out))
  384. # [15:48] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  385. # [16:46] <annevk> http://en.wikipedia.org/wiki/XHTML might need updates as well
  386. # [16:53] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  387. # [16:56] <hsivonen> annevk: feel free to edit :-)
  388. # [16:57] <annevk> It's been said that I hate XHTML
  389. # [16:57] <annevk> Any edit would immediately be reverted
  390. # [16:57] <met_> edit it anonymously
  391. # [16:59] <hsivonen> ooh. they cite the Mozilla Web Author FAQ
  392. # [17:00] <annevk> I'm sure someone else will fix it in due course
  393. # [17:01] <Philip`> http://en.wikipedia.org/w/index.php?title=XHTML&oldid=129295550 - I prefer that version of the facts
  394. # [17:04] <annevk> :)
  395. # [17:05] <hsivonen> :-)
  396. # [17:05] <zcorpan_> hsivonen: "Namespace at-rules are supported." they are supported in HTML mode too
  397. # [17:05] <zcorpan_> (from the faq)
  398. # [17:06] <hsivonen> zcorpan_: do you mean they work right if you introduce other namespaces via DOM manipulation?
  399. # [17:06] <zcorpan_> yes. or if you just declare a bogus namespace then it won't match html elements
  400. # [17:07] <hsivonen> zcorpan_: OK. I take your word for it.
  401. # [17:07] <zcorpan_> html elements are in the xhtml namespace as far as css selectors are concerned
  402. # [17:07] <zcorpan_> in mozilla and opera and safari too iirc
  403. # [17:07] <zcorpan_> (even though they are in the null namespace in the DOM)
  404. # [17:10] <hsivonen> zcorpan_: fix checked in. should appear in the next site rebuild
  405. # [17:10] <hsivonen> zcorpan_: thanks for the report
  406. # [17:10] <zcorpan_> "Other namespaces are supported." and "xml:base is observed when following links." also are no different from HTML, except that you can't use them declaratively
  407. # [17:11] <hsivonen> hmm. I wonder if the point is too subtle for the FAQ
  408. # [17:11] <zcorpan_> perhaps... i realise it's intended to say "you can't use this"
  409. # [17:12] <annevk> not useful to mention I think
  410. # [17:12] <annevk> you can't use them in HTML, you can use them in the DOM
  411. # [17:13] <zcorpan_> yeah, fair enough
  412. # [17:14] * annevk wonders what should happen with var imagedata = { height:1, width:2, data=[...], example:3 }
  413. # [17:15] <annevk> the other question is whether it's useful that you're able to create your own objects...
  414. # [17:15] <annevk> as <canvas> represents a grid that doesn't reflect device pixels
  415. # [17:16] <annevk> it seems extremely easy to get it wrong
  416. # [17:17] <Philip`> It might make extensibility a bit harder too, if ImageData is modified in the future (e.g. to say how many device pixels per canvas pixel, or to indiciate a non-RGB colour space, or whatever) but people are passing in objects with those new attributes missing
  417. # [17:17] <Philip`> s/indiciate/indicate/
  418. # [17:20] <Philip`> It doesn't seem unreasonable to have people write var d; with (document.createElement('canvas')) { width = 100; height = 100; d = getContext('2d').getImageData(0, 0, width, height); }
  419. # [17:20] <Philip`> ...assuming every canvas has the same device pixel / canvas pixel mapping
  420. # [17:21] <annevk> yeah
  421. # [17:21] <Philip`> (I guess there's already an assumption that that mapping doesn't change over time, e.g. if you do getImageData then the user changes their desktop resolution then you do putImageData)
  422. # [17:22] <Dashiva> Philip`: Let's not encourage use of with too much
  423. # [17:22] <annevk> especially since people tend to test only one browser...
  424. # [17:22] <annevk> nothing wrong with with
  425. # [17:22] <Philip`> Dashiva: I generally hate with because it seems confusing and error-prone, but I didn't want to bother declaring another variable :-)
  426. # [17:23] <annevk> this feature allows you to imlement filters and I suppose that in theory you don't really care about the canvas pixels then but authors will break stuff
  427. # [17:24] <Philip`> For image filtering, it would be quite nice if the browser could JIT your JS code into optimised SIMD array operations...
  428. # [17:25] <Philip`> (Actually, I have no idea how fast it is with plain JS operating on arrays of integers)
  429. # [17:28] <Philip`> Oh, one problem with implementing filters...
  430. # [17:28] <Philip`> Normally you want access to both the old and new arrays of pixels
  431. # [17:28] <Philip`> (because you need all the old values in order to compute the new ones)
  432. # [17:29] <Philip`> but that doesn't seem easy with ImageData - you have to somehow copy the .data array into a new array, then modify the values in .data
  433. # [17:30] <Philip`> whereas it'd seem more natural (and more efficient) to use the old values from .data and create a new array, then swap that new array back into the ImageData
  434. # [17:30] <Philip`> (but you can't because the array reference is readonly)
  435. # [17:33] <annevk> you could simply create a new object it seems
  436. # [17:33] <annevk> but given that you can do that it doesn't make much sense for .data to be readonly imo
  437. # [17:34] <annevk> although the design is quite clear I don't think I particularly like these methods
  438. # [17:34] <annevk> I'm pretty sure authors will almost directly rely on them returning specific results
  439. # [17:38] <annevk> cool, bbc guys will show up at XTech
  440. # [17:39] * annevk hopes they can give some info on Dirac
  441. # [17:41] <hsivonen> annevk: do they have a session?
  442. # [17:42] <annevk> dunno, just saw some guy from bbc commenting on molly.com
  443. # [17:44] <maikmerten> I hope Dirac's bitstream specification will be declared stable in a foreseeable timeframe so useful implementation can be assembled
  444. # [17:44] <maikmerten> (that'd be schrodinger.sf.net - dirac's real-life implementation)
  445. # [17:44] * Joins: madmoose (i=madmoose@gateway/web/cgi-irc/beitsahour.net/x-a6a69e0cd54b3b1a)
  446. # [17:45] <Philip`> annevk: Oh, oops, I forgot you could create a new one
  447. # [17:46] <Philip`> http://canvex.lazyilluminati.com/misc/filter.html - takes about 1.5 seconds to do the simplest useful filter on 300x150 pixels
  448. # [17:47] <Philip`> (...in FF3)
  449. # [17:50] <Dashiva> I didn't know crashing my opera was a useful filter, but okay
  450. # [17:50] * annevk will file the bug
  451. # [17:50] <Philip`> Oh, that's not quite the intent
  452. # [17:51] <annevk> it's good
  453. # [17:51] <Philip`> Opera 9.20 avoids crashing, which is good :-)
  454. # [17:51] <annevk> better to discover it now
  455. # [17:51] * Joins: peepo (n=Jay@host81-132-186-246.range81-132.btcentralplus.com)
  456. # [17:53] * Philip` still forgot about imgdata.width != canvas.width when he first wrote this code
  457. # [17:53] <annevk> right
  458. # [17:55] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("Leaving")
  459. # [17:55] <Philip`> (At least the filter algorithm doesn't care about that issue, but I was looping over the wrong array range)
  460. # [17:57] * annevk e-mails the list
  461. # [18:00] <Philip`> It would be alright if imgdata.width != canvas.width all the time in every browser, because then everybody would notice when they first tried testing
  462. # [18:00] <annevk> or simply assume it's 2*
  463. # [18:00] <Philip`> (but that would be silly for implementations which have one canvas pixel per device pixel)
  464. # [18:01] <annevk> the thing is that can paint on half a pixel in theory
  465. # [18:01] <annevk> because everything is float (ugh! thanks Apple) based
  466. # [18:02] <annevk> if that wasn't the case you could just force 1 = 1 i suppose
  467. # [18:03] <Philip`> http://canvaspaint.org/paint.js - their getPixel assumes imgd.width == canvas.width
  468. # [18:03] <Philip`> (Not sure why they commented out that code, though...)
  469. # [18:04] <Philip`> (unless it was just because nobody had implemented getImageData when they wrote that page)
  470. # [18:04] <annevk> didn't work maybe?
  471. # [18:04] * Quits: peepo (n=Jay@host81-132-186-246.range81-132.btcentralplus.com) ("later")
  472. # [18:05] <annevk> Opera getPixel() actually assumes 1=1 as well in some way though I suppose it returns slightly weird things if you painted half a pixel before invoking it or something
  473. # [18:06] * annevk wonders if anybody actually uses the floats
  474. # [18:07] <Philip`> http://svn.sourceforge.net/viewvc/*checkout*/jsmsx/trunk/msx.js?revision=20 - they get it wrong too
  475. # [18:07] <annevk> can you maybe cite those on the list?
  476. # [18:07] <annevk> otherwise I'm willing to do it
  477. # [18:08] <Philip`> I will do - I'll just see if I can find anybody doing it right first :-)
  478. # [18:08] <annevk> (i really like that people are doing MS Paint in <canvas> btw, really nice :) )
  479. # [18:08] <annevk> next: photoshop :)
  480. # [18:10] <Philip`> I noticed there was some new Adobe application where they're written most of the code in Lua, and that kind of thing could work just as well in JS. But I guess they cheated and wrote optimised image-processing code in C++ instead :-(
  481. # [18:10] <annevk> (drawing rectangles seems kind of messed up)
  482. # [18:11] <annevk> <canvas> + XMLHttpRequest could do that :)
  483. # [18:11] <annevk> well, once it supports sending bytes over the wire better
  484. # [18:12] * Dashiva is reminded of ajax <blink>
  485. # [18:19] <Philip`> Ooh, I found one using it correctly
  486. # [18:19] <annevk> oh cool
  487. # [18:21] <annevk> which one?
  488. # [18:25] <Philip`> http://tech.groups.yahoo.com/group/canvas-developers/files/buttons.html - might need to register/login to access that, though
  489. # [18:26] * Joins: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net)
  490. # [18:26] <Philip`> Hmm, it would be easier to find people use canvas getImageData if it didn't use horribly common terms like "canvas" and "getImageData" so searches find people using dozens of other graphics libraries instead
  491. # [18:28] <Philip`> Oh, perhaps http://f1.grp.yahoofs.com/v1/gORFRoOLlxuXtJddXwdSyravD-aFfgNuYoSzjI8vUevuBxus3V1sXs5xckiHKd1osiUpDE_bku-vtGMFPV_M-2JZkLKXTqc/buttons.html works without logging in
  492. # [18:29] <annevk> yeah
  493. # [18:32] <annevk> I wonder what the expected rendering is...
  494. # [18:33] <annevk> The last one and a half button should be blue?
  495. # [18:33] <Philip`> Yep, it switches the red and blue components for the square (2000,0)-(3000,500)
  496. # [18:34] <Philip`> (I've no idea why it does that)
  497. # [18:34] <Philip`> (More precisely, I've no idea why the author decided to make it do that)
  498. # [18:39] * Joins: theoros (n=theoros@ACC8D244.ipt.aol.com)
  499. # [18:40] <annevk> maybe just a test
  500. # [19:10] * Joins: peepo (n=Jay@host81-132-186-246.range81-132.btcentralplus.com)
  501. # [19:22] * Quits: dev0 (i=Tobias@unaffiliated/icefox0) ("dev0 has no reason")
  502. # [19:27] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  503. # [19:46] * Quits: peepo (n=Jay@host81-132-186-246.range81-132.btcentralplus.com) ("later")
  504. # [19:46] * Joins: MichaelMH (n=Michael@87.254.86.84)
  505. # [19:56] * Quits: zcorpan_ (n=zcorpan@84-216-43-239.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  506. # [20:24] * Quits: MichaelMH (n=Michael@87.254.86.84) ("Leaving")
  507. # [20:43] * om_sleep is now known as othermaciej
  508. # [20:43] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  509. # [20:44] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  510. # [20:44] * Philip` realises that drawImage(toDataURL) won't work as expected because it'll convert device pixels into image pixels, then draw image pixels as canvas pixels
  511. # [20:44] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  512. # [20:45] * Joins: weinig|food (n=weinig@m810f36d0.tmodns.net)
  513. # [20:46] * weinig|food is now known as weinig
  514. # [20:53] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  515. # [21:16] * othermaciej is now known as om_out
  516. # [21:18] * Joins: jruderman_ (n=jruderma@c-67-169-183-228.hsd1.ca.comcast.net)
  517. # [21:18] * Quits: jruderman (n=jruderma@c-67-169-183-228.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  518. # [21:27] * Joins: bzed (n=bzed@dslb-084-059-126-057.pools.arcor-ip.net)
  519. # [21:32] * Joins: jruderman (n=jruderma@c-67-169-183-228.hsd1.ca.comcast.net)
  520. # [21:32] * Quits: jruderman_ (n=jruderma@c-67-169-183-228.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  521. # [21:41] * Quits: jruderman (n=jruderma@c-67-169-183-228.hsd1.ca.comcast.net)
  522. # [21:46] <annevk> Philip`, images are drawn as CSS pixels
  523. # [21:46] <annevk> actually, isn't that defined?
  524. # [21:46] <annevk> treat an image pixel as a canvas pixel or something?
  525. # [21:46] <annevk> yeah, that's defined
  526. # [21:46] <annevk> "interpreted such that one CSS pixel in the image is treated as one unit in the canvas coordinate space"
  527. # [21:47] <Philip`> Oh, right
  528. # [21:47] <Philip`> That's quite confusing - I expected it was equivalent to drawImage(img, 0, 0, img.width, img.height) because anything else is weird
  529. # [21:48] <Philip`> That also means sw,sh and dw,dh are different units, which is confusing
  530. # [21:49] <annevk> huh?
  531. # [21:49] <Philip`> Actually, not sure what I mean
  532. # [21:49] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  533. # [21:49] <annevk> it should be equivalent to that...
  534. # [21:50] * Philip` is confused more now
  535. # [21:50] <annevk> one image pixel is mapped to a canvas pixel
  536. # [21:50] <Philip`> If I have <canvas width=100 height=100> and want to draw img to fill it, would I say ctx.drawImage(img, 0, 0, 100, 100)?
  537. # [21:51] <Philip`> (and img is a 100x100 PNG or something)
  538. # [21:51] <Philip`> Oh
  539. # [21:51] <Philip`> but img.width is in CSS pixels too, not real pixels
  540. # [21:51] <annevk> that should work
  541. # [21:51] <Philip`> so img.width is not necessarily 100
  542. # [21:51] <annevk> it is
  543. # [21:52] <annevk> one image pixel is one CSS pixel
  544. # [21:52] <Philip`> Still confused :-)
  545. # [21:52] * Joins: kingryan (n=kingryan@banff-72-29-239-177.mycanopy.net)
  546. # [21:53] <annevk> you have device pixels, CSS pixels, canvas pixels and image pixels
  547. # [21:53] <annevk> the latter is really equivalent to CSS pixels for the purposes of visual browsers aiui
  548. # [21:53] <annevk> drawImage() takes one CSS pixel and makes it a canvas pixel
  549. # [21:54] <annevk> so a 100x100 PNG would fill a 100x100 canvas
  550. # [21:54] <annevk> and styling an image using CSS with 'width:200px' would also not modify a 200px width image (ever)
  551. # [21:54] <annevk> s/width image/wide image/
  552. # [21:55] <Philip`> I think what I expect is that <img src="some-100x100-image.png"><canvas width=100 height=100>...ctx.drawImage(img, 0, 0, img.width, img.height) would fill the canvas, and ctx.drawImage(img, 0, 0) would do exactly the same, regardless of whatever the browser decides to do
  553. # [21:55] <Philip`> ...which seems to be what is specified, so that's alright, unless I'm wrong
  554. # [21:55] <annevk> that's what the spec says
  555. # [21:56] <Philip`> Okay - then it still leaves the problem of converting device pixels to image pixels in toDataURL (which doesn't seem specified), and then treating image pixels = CSS pixels = canvas pixels when drawImaging again
  556. # [21:57] <Philip`> (I'd assume toDataURL isn't meant to lose all the high-res data if you've got >1 device pixel per canvas pixel, because that wouldn't be nice, so it has to map device pixels onto image pixels)
  557. # [21:57] <annevk> toDataURL makes a PNG
  558. # [21:57] <annevk> oh you mean that 1 canvas pixel must become 1 image pixel?
  559. # [21:57] <Philip`> Will toDataURL on a <canvas width=100 height=100> always make a 100x100 PNG? Or does that depend on how many device pixels are in the canvas?
  560. # [21:58] <annevk> 1 canvas pixel becomes 1 image pixel imo
  561. # [21:58] <Philip`> So toDataURL/drawImage will lose data?
  562. # [21:58] * Joins: peepo (n=Jay@host81-132-186-246.range81-132.btcentralplus.com)
  563. # [21:58] <annevk> might
  564. # [21:58] <Philip`> That would seem quite annoying if you're trying to use toDataURL to implement a 'save image' button
  565. # [21:59] <annevk> make a high res <canvas>
  566. # [21:59] <annevk> and scale it down using CSS
  567. # [21:59] <annevk> I'm actually all for going completely in that direction
  568. # [21:59] <annevk> and have getImageData and putImageData do the same
  569. # [21:59] <annevk> far more predictable
  570. # [22:00] <Philip`> Have the author explicitly make a high-res canvas when they want to support users with high-res displays?
  571. # [22:00] <annevk> no, when they want to support high-res output
  572. # [22:01] <annevk> <canvas height="1000" width="1000" style="height:100px;width:100px">
  573. # [22:01] <Philip`> And then toDataURL would give a 1000x1000 image
  574. # [22:02] <annevk> yeah
  575. # [22:02] <annevk> I think it does now
  576. # [22:02] <Philip`> What if the user already has a clever browser and a really high-res display, so it puts 10x10 device pixels per canvas pixel?
  577. # [22:02] <annevk> same
  578. # [22:02] <Philip`> and then it ends up with 10000x10000 device pixels for that canvas
  579. # [22:02] <annevk> no
  580. # [22:03] <annevk> well, maybe if it does some clever subpixel rendering...
  581. # [22:03] <Philip`> Otherwise it would have to depend on the CSS computed size
  582. # [22:03] <Philip`> Or it would have to always have 1 device pixel = 1 canvas pixel
  583. # [22:03] <Philip`> (where the latter case makes everything easy, as far as I can see :-) )
  584. # [22:03] <annevk> no it wouldn't
  585. # [22:04] <annevk> CSS pixel != device pixel
  586. # [22:04] <annevk> you'd get weird styling effects and such
  587. # [22:04] * Quits: peepo (n=Jay@host81-132-186-246.range81-132.btcentralplus.com) ("later")
  588. # [22:05] <Philip`> If I have <canvas width=1000 height=1000> and a browser with 10x10 device pixels per canvas pixels, then the "size of the coordinate space" is 1000x1000, so that would give 10000x10000 device pixels?
  589. # [22:05] <annevk> it depends on display
  590. # [22:05] <annevk> on the device, really
  591. # [22:06] <annevk> device pixels = actual rendering
  592. # [22:06] <annevk> so it's not really about the browser
  593. # [22:06] <Philip`> However many device pixels it gives, does <canvas width=1000 height=1000 style="width:100px; height:100px"> give the same number?
  594. # [22:07] <annevk> unlikely
  595. # [22:07] <annevk> actually, no
  596. # [22:07] <Philip`> If it depends on the computed CSS size, what would happen with <canvas style="width:100%"> when the user resizes their browser and the computed CSS size changes?
  597. # [22:08] <annevk> the canvas pixel to CSS pixel ratio would change?
  598. # [22:08] <annevk> (amount of canvas pixels is always fixed)
  599. # [22:08] <Philip`> But the number of device pixels in the canvas would stay the same?
  600. # [22:09] <annevk> (as in, unsigned integer)
  601. # [22:09] <annevk> Philip`, no, device pixels is the amount of pixels used to render the canvas on the screen (= device)
  602. # [22:10] <Philip`> How can the browser change the number of device pixels being used to store the image in the canvas, without making a mess of the canvas's contents?
  603. # [22:10] * Quits: kingryan (n=kingryan@banff-72-29-239-177.mycanopy.net)
  604. # [22:11] <annevk> Philip`, I would think the browser stores the data internally and eventually scales it based on CSS provided and puts it on the screen
  605. # [22:12] <annevk> that's sort of what happens with scaled images iirc
  606. # [22:12] <Philip`> With things like getImageData, "device pixels" is used for the underlying pixel data that's stored internally
  607. # [22:13] <annevk> it's all a bit confusing
  608. # [22:13] <Philip`> I would tend to agree ;-)
  609. # [22:13] <annevk> but if that's your point I agree with your earlier suggestion about 1 device pixel = 1 canvas pixel
  610. # [22:14] <annevk> and by default 1 canvas pixel would be 1 css pixel
  611. # [22:15] <Philip`> The only way that seems to make sense to me is if the underlying pixel data stores exactly one pixel of data per canvas pixel, and getImageData/putImageData/toDataURL/drawImage act on that pixel data, and then that bitmap just gets rescaled by CSS or whatever at the final render-to-screen stage
  612. # [22:16] <annevk> http://twitter.com/annevk/statuses/61777592
  613. # [22:16] * Joins: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  614. # [22:16] <annevk> yeah
  615. # [22:16] <annevk> I wonder what other implementors would think
  616. # [22:17] <annevk> it would also allow us to get rid of all the floats...
  617. # [22:17] <Philip`> so a browser never has a higher-resolution bitmap to store the canvas data - it just scales up and looks a bit blurry
  618. # [22:17] <Philip`> (or the author makes canvas.width/height larger so there's more canvas pixels per monitor pixel)
  619. # [22:17] <Philip`> (if the author cares enough and makes sure they're not doing it all wrong)
  620. # [22:18] <Philip`> (and if the author has some way of determining that a certain user would benefit from a bigger canvas)
  621. # [22:18] <annevk> not sure if you can forbid UAs to do anti-alias
  622. # [22:19] <annevk> but getting the basics more consistent would be good
  623. # [22:19] <Philip`> Not sure why they'd be forbidden to anti-alias...
  624. # [22:19] <annevk> well, if you don't allow "subpixel" rendering
  625. # [22:19] <annevk> it might be tricky to smooth things now and then
  626. # [22:20] <annevk> (given that UAs actually do that now, dunno)
  627. # [22:20] <Philip`> They could do subpixel rendering inside a function, but the result would just be four bytes in a bitmap somewhere, so you could always retrieve and save and redraw the pixels without losing any information
  628. # [22:21] <Philip`> I suppose that would disallow supersampling antialiasing, where you just render to a big bitmap then scale down, but I didn't think anyone does that since it uses far too much memory
  629. # [22:23] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  630. # [22:25] * Quits: maikmerten (n=maikmert@L82a0.l.pppool.de) ("Leaving")
  631. # [22:25] <Philip`> Ah, an email - I think I agree with that, assuming I'm not mixing the terminology up again :-)
  632. # [22:27] * annevk wonders if Apple guys would agree to getting rid of floats
  633. # [22:28] <Philip`> Which floats do you mean?
  634. # [22:28] <Philip`> It's still useful being able to draw to subpixel locations, because antialiasing does the right thing
  635. # [22:28] <Philip`> It's only really getImageData/putImageData where you want actual real pixels, not subpixels
  636. # [22:28] <annevk> hmm ok
  637. # [22:29] <annevk> but what if you put four different color subpixels into one pixel
  638. # [22:29] <annevk> what would getImageData do?
  639. # [22:29] * annevk ponders
  640. # [22:30] <Philip`> If you draw a solid 0.5x0.5 green rectangle inside one pixel, it will modify the internal bitmap to have a rgba(0, 255, 0, 0.25) value there
  641. # [22:30] <Philip`> (because the antialiasing algorithm decides that pixel has 25% coverage by what you're drawing, which it approximates by giving 25% alpha across the whole pixel)
  642. # [22:30] <annevk> feel free to follow-up there with that
  643. # [22:33] <annevk> I suppose your idea might make it more acceptable
  644. # [22:40] <Philip`> http://canvex.lazyilluminati.com/misc/subpixel.html - 0.5x0.5 rectangles are drawn the same as 1x1 alpha=0.25 rectangles
  645. # [22:41] <annevk> you get vastly different results in Firefox and Opera
  646. # [22:42] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  647. # [22:44] <annevk> I think Opera does indeed do what you suggest
  648. # [22:44] <annevk> Firefox doesn't
  649. # [22:45] <Philip`> That's the effects of their CSS image resizing - Opera seems to be just repeating each pixel 100x100 times, Firefox 3 is doing smooth scaling (like Opera normally does with resized images), but in both cases the actual canvas is just a 3x3 array of pixels (which is what I want)
  650. # [22:47] <annevk> oh ok
  651. # [22:47] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  652. # [22:47] <annevk> so the actual back end does indeed do 1 <canvas> device pixel = 1 canvas pixel
  653. # [22:48] <annevk> I suppose that makes sense
  654. # [22:59] <annevk> some people actually think the HTML4 spec is more clear
  655. # [22:59] <annevk> see http://www.456bereastreet.com/archive/200705/is_html_5_a_slippery_slope/#comment17
  656. # [22:59] * annevk hopes he will give some suggestions on how to improve the text
  657. # [23:00] * annevk is totally fine with the current text
  658. # [23:00] <annevk> well, the reading bit of it
  659. # [23:03] <annevk> (I was quite confused above. Confusing the internal <canvas> with the output on screen...)
  660. # [23:03] <annevk> (It just hit my why the difference in rendering is hardly an indicator of what's going on in this case :) )
  661. # [23:05] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  662. # [23:09] <annevk> Philip`, can't the anti-aliasing algorithm differ per browser though?
  663. # [23:14] <Philip`> In theory it could, but in practice everyone seems to implement it in the standard way - a pixel of which a fraction 'n' is covered by (r,g,b,a) is just treated the same as a pixel entirely covered by (r,g,b,a*n)
  664. # [23:15] <Philip`> I don't know of any other ways to do it, without storing extra data (e.g. lots of subpixels) per pixel
  665. # [23:15] <Philip`> (and people don't really do the latter, in my experience)
  666. # [23:15] <Philip`> (*limited experience)
  667. # [23:15] <annevk> k
  668. # [23:16] <annevk> nice follow-up e-mail
  669. # [23:17] <Philip`> There are differences in how you decide how much of a pixel is covered by whatever's being drawn if you're e.g. drawing a gradient or a smoothly-filtered image (so it's not a single colour covering some fraction of the pixel), but still the output is a single (r,g,b,a) per pixel, and those differences don't matter much
  670. # [23:17] <annevk> I suppose height and width are still useful on ImageData
  671. # [23:18] <Philip`> I think they're still useful since otherwise you'd usually have to remember the width and height in extra variables somewhere, because you're going to be looping over them or multiplying by them
  672. # [23:19] <annevk> do you have tests on imagedata = {} not matching the actual definition?
  673. # [23:20] <Philip`> (In that button-drawing site I found where they actually used ImageData.width/height correctly, I think that was probably accidental and they just used width/height because they were convenient ways to access the numbers)
  674. # [23:21] <Philip`> I've not done any tests with ImageData
  675. # [23:21] <annevk> k
  676. # [23:21] <annevk> just have to catch a Hixie to update the spec
  677. # [23:24] <Philip`> http://www.w3.org/TR/html401/present/graphics.html#edef-B - I think the list there (TT/I/B/...) makes HTML4 far more readable, compared to HTML5 where the definitions are spread all over the place
  678. # [23:26] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  679. # [23:27] <annevk> Elements could supposedly have an introduction chapter with such informative descriptions...
  680. # [23:28] <annevk> the only thing it says is that they must be properly nested
  681. # [23:28] <annevk> no other requirements...
  682. # [23:29] <Philip`> The lack of requirements and of precision is probably what makes it readable :-)
  683. # [23:29] <annevk> id and class have no user agent requirements either
  684. # [23:30] <annevk> I suppose :)
  685. # [23:30] <annevk> it's a tutorial for authors :)
  686. # [23:30] <annevk> with a spec sticker on top and some DTD grammar here and there
  687. # [23:36] <annevk> I also believe that authors are better served with more interoperability than with a spec. Some vocal authors seem to disagree though
  688. # [23:37] * Quits: weinig (n=weinig@m810f36d0.tmodns.net)
  689. # [23:37] <annevk> They are somehow under the impression that a clearer specification will improve authoring practices...
  690. # [23:37] <annevk> "Let me hit you with the specification-clue-stick"
  691. # [23:43] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  692. # [23:44] * Quits: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  693. # [23:50] * Joins: theoros` (n=theoros@ACC8D244.ipt.aol.com)
  694. # [23:50] * Quits: theoros` (n=theoros@ACC8D244.ipt.aol.com) (Read error: 104 (Connection reset by peer))
  695. # Session Close: Sun May 13 00:00:00 2007

The end :)