/irc-logs / freenode / #whatwg / 2011-03-31 / end

Options:

  1. # Session Start: Thu Mar 31 00:00:00 2011
  2. # Session Ident: #whatwg
  3. # [00:02] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Ping timeout: 248 seconds)
  4. # [00:03] <aho> b64 is about the same
  5. # [00:03] <zewt> gzipped base64, 1086 bytes ... very close
  6. # [00:03] <aho> b64=33% bloat, gzip gets rid of that again :>
  7. # [00:03] <zewt> (well--less close if it's a lot of data, but for a file index it's close enough)
  8. # [00:04] * Quits: cying (~cying@173-13-176-101-sfba.hfc.comcastbusiness.net) (Read error: Connection reset by peer)
  9. # [00:04] * Joins: cying (~cying@173-13-176-101-sfba.hfc.comcastbusiness.net)
  10. # [00:04] <zewt> and being able to look at the index (with your eyes and not special tools), pull out an sha-1, run sha1sum on a file and compare them (again with no special tools)--that's a general real-world win
  11. # [00:05] <zewt> can't do that if your hashes are encoded in an unusual way
  12. # [00:06] <aho> i do know one other person who does it the same way and who came up with it independently :>
  13. # [00:06] <zewt> also stop with the md5 already it's 2011 :P
  14. # [00:07] <aho> if you're only interested in detecting changes, md5 works fine
  15. # [00:08] <zewt> no reason to use md5 in anything new--default to sha-1
  16. # [00:08] <zewt> even if there's no particular reason to for an application, it helps to get out of the habit :P
  17. # [00:09] * Quits: matijsb (~matijsb@5353CD69.cm-6-4d.dynamic.ziggo.nl) (Quit: Leaving.)
  18. # [00:09] <aho> why not skein then? :>
  19. # [00:10] <aho> or sha-2 for that matter
  20. # [00:13] <zewt> well, sha-1 isn't considered obsolete today; md5 is
  21. # [00:16] <aho> sha-1 outputs 20 bytes instead of 16... meh :I
  22. # [00:16] <aho> http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms
  23. # [00:17] <aho> mhmh... ripemd-128 :>
  24. # [00:17] <aho> never heard of that one
  25. # [00:23] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Quit: Now time for the weather. Tiffany?)
  26. # [00:23] * Joins: mkwst (u395@gateway/web/irccloud.com/x-mpoyozxrfrpqhjsu)
  27. # [00:24] * Joins: demet8 (~demet8@7.186.8.67.cfl.res.rr.com)
  28. # [00:26] * Quits: F1LT3R (~f1lt3r@75-150-66-249-NewEngland.hfc.comcastbusiness.net) (Quit: less catch, more try)
  29. # [00:27] * Parts: demet8 (~demet8@7.186.8.67.cfl.res.rr.com)
  30. # [00:30] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Remote host closed the connection)
  31. # [00:37] * Quits: saba (~foo@unaffiliated/saba) (Ping timeout: 250 seconds)
  32. # [00:38] * Quits: sephr (~Eli@c-98-235-63-240.hsd1.pa.comcast.net) (Quit: Leaving)
  33. # [00:39] * Joins: tw2113 (~tw2113@fedora/tw2113)
  34. # [00:57] * Quits: ap (~ap@17.246.18.51) (Remote host closed the connection)
  35. # [00:57] * Joins: ap (~ap@17.203.15.167)
  36. # [00:58] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  37. # [01:00] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Remote host closed the connection)
  38. # [01:02] * Joins: Oskar_ (~chatzilla@78-69-155-129-no176.tbcn.telia.com)
  39. # [01:02] * Oskar_ is now known as potatis_invalido
  40. # [01:05] * Quits: Xano (~bart@524B818E.cm-4-4c.dynamic.ziggo.nl) (Quit: Beer o'clock!)
  41. # [01:05] * Joins: erlehmann (~erlehmann@82.113.99.33)
  42. # [01:06] * Quits: tw2113 (~tw2113@fedora/tw2113) (Remote host closed the connection)
  43. # [01:06] * Joins: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
  44. # [01:07] * Quits: svl (~me@186.130.48.69) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  45. # [01:11] * Joins: Jak (~chatzilla@221.201.219.217)
  46. # [01:11] * Joins: tw2113 (~tw2113@fedora/tw2113)
  47. # [01:12] * Joins: ho (opera@221.201.219.217)
  48. # [01:13] * Parts: ho (opera@221.201.219.217)
  49. # [01:14] * Quits: erlehmann (~erlehmann@82.113.99.33) (Quit: Ex-Chat)
  50. # [01:16] * Quits: Jak (~chatzilla@221.201.219.217) (Client Quit)
  51. # [01:18] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Quit: mdelaney)
  52. # [01:18] * Joins: erlehmann (~erlehmann@82.113.99.33)
  53. # [01:20] * Joins: bentruyman (~bentruyma@24-148-24-69.c3-0.prs-ubr2.chi-prs.il.cable.rcn.com)
  54. # [01:21] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 248 seconds)
  55. # [01:27] <aho> are websockets now part of html5?
  56. # [01:27] <aho> http://dev.w3.org/html5/websockets/ <- this url seems to suggest that
  57. # [01:27] <Hixie> define "html5"
  58. # [01:27] * Joins: Duke___ (~Duke@187.50.13.57)
  59. # [01:27] <aho> http://www.whatwg.org/C <- that :P
  60. # [01:27] <Hixie> that's not "HTML5", that's Web Applications 1.0
  61. # [01:28] <Hixie> the Web Sockets API is part of Web Applications 1.0, the Web Sockets Protocol is not.
  62. # [01:28] <aho> well, it was html5 prior to that whole "dropping the version number thing", right?
  63. # [01:28] <Hixie> http://whatwg.org/html was labeled "html5" for a while
  64. # [01:28] <Hixie> but that's a subset of http://whatwg.org/C
  65. # [01:29] <Hixie> (the C stands for Complete)
  66. # [01:29] <aho> ah... ok
  67. # [01:29] <Hixie> the FAQ tries to explain it better if you're still confused :-)
  68. # [01:32] <aho> and the /protocol/ is part of... some ietf thing?
  69. # [01:34] * wilhelm approves of the kitchen sink illustration.
  70. # [01:34] <aho> http://www.brucelawson.co.uk/2010/meet-newt-new-exciting-web-technologies/
  71. # [01:34] <aho> lets go with that
  72. # [01:34] <aho> css3? NEWT. webworkers? NEWT. canvas? NEWT. :>
  73. # [01:35] * Joins: Yuhong (~chatzilla@pool-71-112-243-235.sttlwa.dsl-w.verizon.net)
  74. # [01:36] * Joins: Amorphous (jan@unaffiliated/amorphous)
  75. # [01:38] <potatis_invalido> Pronounced it'd sound like the Swedish word for pleasure.
  76. # [01:38] * Quits: erlehmann (~erlehmann@82.113.99.33) (Quit: Ex-Chat)
  77. # [01:38] <aho> sounds about right
  78. # [01:38] <aho> :>
  79. # [01:39] <potatis_invalido> Haha yeah
  80. # [01:40] <potatis_invalido> What fun projects are you people working on? (With emphasis on the word fun)
  81. # [01:40] <aho> http://mbtic.com/ddd
  82. # [01:41] <aho> old site, old markup, ignore that :>
  83. # [01:41] <potatis_invalido> It's like the ice skating in Pokémon
  84. # [01:41] <aho> never played any pokemon game
  85. # [01:41] <potatis_invalido> but way cooler
  86. # [01:41] <aho> :)
  87. # [01:42] <potatis_invalido> I'm working on a Hammer Editor clone
  88. # [01:42] <potatis_invalido> for the web
  89. # [01:42] <potatis_invalido> Hammer Editor is the map editor for Half-Life and Source games
  90. # [01:42] <potatis_invalido> 3D FPS games in other words
  91. # [01:42] <aho> ah
  92. # [01:42] <aho> i only used radiant (quake3's)
  93. # [01:43] <aho> and some really old one for quake1
  94. # [01:43] <aho> no idea how that one was called
  95. # [01:43] <potatis_invalido> I've tried radiant. Found it confusing
  96. # [01:43] <aho> it is
  97. # [01:43] <aho> got some curve to it
  98. # [01:43] <potatis_invalido> quark?
  99. # [01:43] <aho> probably :)
  100. # [01:43] <aho> it's been a while
  101. # [01:44] <Hixie> aho: web socket protocol is being done by the ietf hybi group
  102. # [01:44] <potatis_invalido> Did you finish any maps?
  103. # [01:44] <aho> i made some midair maps
  104. # [01:44] * Quits: chriseppstein (~chris@64.134.223.197) (Ping timeout: 250 seconds)
  105. # [01:44] <Yuhong> "I wonder what Arjun Ray is doing these days. one could spend a weekend reading his ciwah posts from the late 1990s "
  106. # [01:44] <Yuhong> People have forgotten how the Netscape monopoly was bad.
  107. # [01:45] <aho> but that mod was experimental and only a dozen people ever played it :>
  108. # [01:45] <Yuhong> Back in 1995 or so.
  109. # [01:45] <potatis_invalido> I've been mapping Half-Life ~5 years now. Still haven't been able to produce anything worth looking at :P
  110. # [01:45] * Joins: erlehmann (~erlehmann@82.113.99.33)
  111. # [01:45] <Yuhong> It basically killed HTML 3.0, which existed as HTML+ before Netscape even existed.
  112. # [01:45] <potatis_invalido> too short attention span
  113. # [01:46] <aho> midair = typically just one room... maybe void... maybe lava... that's about it
  114. # [01:46] <potatis_invalido> No platforms or anything?
  115. # [01:46] * Philip` vaguely remembers that he gave up on making Quake maps before any GUI editor was released, when you had to write the whole level's brush positions in a text file by hand (and then spend two hours computing the lighting maps)
  116. # [01:46] <Yuhong> It delayed adoption of style sheets for years, while they invented their own CENTER and FONT tags.
  117. # [01:46] <aho> RL only, crazy vertical knockback, the higher the enemy is in the air, the more damage they receive
  118. # [01:47] <Yuhong> (First draft of CSS dates around the time of Netscape 0.9)
  119. # [01:47] <aho> it's some qw game type
  120. # [01:47] <potatis_invalido> I made a room in the .map format for Half-Life once (it's the same format as for Quake)
  121. # [01:48] <potatis_invalido> I can't imagine what it'd be like making an entire map like that
  122. # [01:48] <Yuhong> Reading Arjun Ray's posts will make all that clear.
  123. # [01:48] <potatis_invalido> Are the DaDaDash levels randomly generated?
  124. # [01:48] <aho> ye
  125. # [01:49] <aho> there will be real ones in the future though
  126. # [01:49] <potatis_invalido> Ok, that explains why it's so easy :P
  127. # [01:49] <aho> and two extra twists
  128. # [01:49] <potatis_invalido> not getting any harder, I should have said
  129. # [01:49] <aho> http://i.imgur.com/EKhMK.png <- it sometimes creates something interesting though
  130. # [01:49] <aho> <:
  131. # [01:50] <potatis_invalido> Indeed
  132. # [01:50] <erlehmann> try building concave-convex shapes
  133. # [01:51] <aho> ~4.5kb js.gz and 59.6 for the resource blob. it's fairly compact :)
  134. # [01:51] <potatis_invalido> Resource blob? Are all images in one file?
  135. # [01:51] <potatis_invalido> and sounds*
  136. # [01:52] <aho> everything
  137. # [01:52] <aho> it's just those two files
  138. # [01:52] <aho> check the net panel ;)
  139. # [01:53] <potatis_invalido> How did you pull that off? Do you generate data: URIs to load the sounds and images?
  140. # [01:53] <aho> http://mbtic.com/games/dadadash/dadadash-ogg.ibz
  141. # [01:53] <aho> it's like mxhr, but with an index
  142. # [01:53] <aho> name,type,length... and so forth... then a ';' followed by the b64 data uris
  143. # [01:54] <potatis_invalido> Interesting
  144. # [01:54] <aho> with gzip it's about the same size as a zip
  145. # [01:54] <potatis_invalido> I might consider doing something similar for my app
  146. # [01:55] <aho> we also tried some other stuff... like b64-ing on the client side, but that turned out to be too slow
  147. # [01:55] <aho> we also tried tar.gz :)
  148. # [01:55] <potatis_invalido> Do you need to b64 it though?
  149. # [01:55] <aho> way. too. slow.
  150. # [01:55] <aho> ye
  151. # [01:56] <aho> there is no other way to hand those bytes over to image or audio
  152. # [01:56] <aho> so, i do need b64 at some point
  153. # [01:56] <potatis_invalido> Is it impossible to use data: with binary data?
  154. # [01:56] <zewt> there's still no api for generating blobs manually, is there?
  155. # [01:56] * Quits: Yuhong (~chatzilla@pool-71-112-243-235.sttlwa.dsl-w.verizon.net) (Quit: ChatZilla 0.9.86.1 [Firefox 4.0/20110318052756])
  156. # [01:56] <zewt> which is really what's wanted for this sort of thing
  157. # [01:57] <zewt> well ... you could XHR the whole file to get a File, and slice the individual files, but XHR isn't too great for resource loading
  158. # [01:57] <aho> i'm using xhr for this
  159. # [01:58] <aho> there isn't any other option, is there?
  160. # [01:58] <zewt> iirc some browsers simply never cache xhr :(
  161. # [01:58] <zewt> (opera?)
  162. # [01:59] <zewt> if you use xhr (xhr2, rather), and if the individual files aren't compressed (use HTTP compression instead), you could slice the individual Files from the XHR result, then use object URLs to load them as resources--so you never have to manipulate the data in JS directly
  163. # [01:59] <zewt> (havn't looked at how you're doing it)
  164. # [02:00] <aho> object urls?
  165. # [02:00] <zewt> URL.createObjectURL(file/blob) -> URL
  166. # [02:01] <aho> does that work with ff/opera/chrome/ie9?
  167. # [02:02] <zewt> ff4/chrome 9+ supports it, iirc; don't know about ie9, don't think opera does
  168. # [02:02] <zewt> also the API has been in minor flux so the name has changed (easy to work around, just fyi)
  169. # [02:03] * Joins: sephr (~Eli@c-98-235-63-240.hsd1.pa.comcast.net)
  170. # [02:03] <potatis_invalido> I can confirm that there's no URI object in Opera 11.10 Beta
  171. # [02:04] <zewt> webkitURL.createObjectURL in chrome 10
  172. # [02:04] <zewt> (and revokeObjectURL)
  173. # [02:05] * Joins: jochen___ (~jochen@nat/google/x-oxbpdigyunshjtkv)
  174. # [02:07] * Joins: mdelaney_ (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
  175. # [02:07] * mdelaney_ is now known as mdelaney
  176. # [02:08] <zewt> if you want to see why I hate data: URLs, try context menu->view image on a large canvas in FF :P
  177. # [02:09] * Quits: jochen__ (~jochen@nat/google/x-poulbossfaoovdbv) (Ping timeout: 240 seconds)
  178. # [02:09] * jochen___ is now known as jochen__
  179. # [02:09] <zewt> (which I *wouldn't* call a QoA issue: code that deals with URLs should not have to be engineered to deal with multiple-megabyte URLs)
  180. # [02:09] * mdelaney is now known as mdelaney-afk
  181. # [02:10] <aho> hmhm... interesting
  182. # [02:11] <aho> i only knew that something like that was in the works, but i didn't know how it's called nor how it was supposed to work :>
  183. # [02:12] <potatis_invalido> Does DaDaDash only generate games that can be solved?
  184. # [02:12] <aho> yes
  185. # [02:12] <aho> (the level is created in reverse)
  186. # [02:12] <potatis_invalido> Maybe that's what I need to do
  187. # [02:12] <potatis_invalido> Think in reverse
  188. # [02:13] <aho> ye, that's the idea... it's 100% pure backtracking :>
  189. # [02:13] <potatis_invalido> That did it.
  190. # [02:13] <aho> :)
  191. # [02:14] <potatis_invalido> It's quite entertaining for such a simple game
  192. # [02:14] <zewt> puzzle games just make me want to write programs to solve them for me
  193. # [02:14] <potatis_invalido> Haha
  194. # [02:15] * Quits: tndH (~Rob@cpc11-seac19-2-0-cust116.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
  195. # [02:15] <potatis_invalido> The thought does cross my mind from time to time
  196. # [02:15] <potatis_invalido> I'm a FreeCell adict.
  197. # [02:15] <aho> if you got java installed you can also try another overly pure game of mine: http://kaioa.com/jws/jnlp_na/fuzetsu.jnlp
  198. # [02:15] <aho> this one is 100% bullet scraping
  199. # [02:15] <aho> :>
  200. # [02:16] <aho> it's a 4k game, by the way (i.e. the whole thing is <= 4096 bytes)
  201. # [02:16] <potatis_invalido> How do you play? (I didn't miss a help screen, did I?)
  202. # [02:17] <aho> get close to the bullets, but dont touch them with the white dot in the middle
  203. # [02:17] <aho> that's it :>
  204. # [02:17] <potatis_invalido> oh, ok
  205. # [02:17] <aho> only risk/reward :)
  206. # [02:18] <potatis_invalido> HA! HA!
  207. # [02:18] <aho> evil, eh? ;D
  208. # [02:19] <potatis_invalido> Indeed
  209. # [02:19] * Joins: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  210. # [02:19] <aho> there are 22 or 23 levels
  211. # [02:21] <aho> http://kaioa.com/k/double_winder.png <- the level editor :)
  212. # [02:23] <potatis_invalido> Wasn't it more work creating a level editor than it'd be doing it manually? (This is coming from someone who has almost no experience with Java)
  213. # [02:24] <aho> there are 8 parameters per emitter and there can be up to 3 emitters (mid, left, right)
  214. # [02:24] <aho> finding interesting values is a lot of trial and error
  215. # [02:24] <aho> the editor took only a few hours
  216. # [02:24] <potatis_invalido> Heh, no way I'd survive 3 of them
  217. # [02:25] <aho> http://kaioa.com/k/fuzetsu4.png
  218. # [02:25] <aho> http://kaioa.com/k/fuzetsu5.png
  219. # [02:25] <aho> :)
  220. # [02:26] * Joins: miketaylr (~miketaylr@user-160vrg5.cable.mindspring.com)
  221. # [02:26] <aho> creating an editor is usually worth it
  222. # [02:26] * Quits: othermaciej (~mjs@17.246.16.190) (Quit: othermaciej)
  223. # [02:27] <aho> in this case it easily saved me from /days/ of change, compile, start, test :>
  224. # [02:28] <potatis_invalido> Right. I forgot that Java is compiled.
  225. # [02:28] <aho> http://www.youtube.com/watch?v=eJfO5Z2deKc <- integrated level editor :)
  226. # [02:29] * Joins: othermaciej (~mjs@17.246.16.190)
  227. # [02:29] <potatis_invalido> I love games where it's simple to make maps
  228. # [02:29] <potatis_invalido> like Worms, Cell Block or Super Mario War
  229. # [02:29] <potatis_invalido> or N
  230. # [02:30] <aho> imo it's important to have a very high turn-over rate
  231. # [02:31] <aho> doom3 was interesting in that regard
  232. # [02:31] <potatis_invalido> If you're a Half-Life player you might have heard of Entmod. It's a server-side plugin which allows players to modify and copy world objects. You can build houses, trains and stuff.
  233. # [02:31] <aho> you could just back and forth between the editor and the game
  234. # [02:31] <aho> and you also got the real lighting right off the bat :)
  235. # [02:31] <potatis_invalido> Sounds cool. I've been meaning to try Doom 3.
  236. # [02:32] <potatis_invalido> I love the old games.
  237. # [02:33] <potatis_invalido> I actually played an Ultimate Doom co-op game with a couple of friends a few hours ago
  238. # [02:33] <aho> doom3 is kinda meh imo .)
  239. # [02:33] <aho> but the engine was pretty interesting back then
  240. # [02:33] <aho> well, you can grab the game for 5 bucks nowadays
  241. # [02:34] <potatis_invalido> I read they plan to release the source code once Rage is done
  242. # [02:35] <potatis_invalido> should spawn some interesting projects
  243. # [02:35] <aho> right away?
  244. # [02:36] <potatis_invalido> "At the QuakeCon 2009, Carmack said that he planned to petition ZeniMax Media to release the id Tech 4 source upon the release of Rage (expected in 2011)"
  245. # [02:36] <potatis_invalido> id Tech 4 is Doom 3's engine
  246. # [02:36] <aho> ye, rage is tech5
  247. # [02:37] <aho> thought you meant tech5 :)
  248. # [02:37] <potatis_invalido> Oh
  249. # [02:37] <potatis_invalido> LOL
  250. # [02:37] <potatis_invalido> I'm normally not impressed by graphics and such but Rage looks pretty sweet from the few images I've seen
  251. # [02:38] <aho> hope we'll see some kind-of impressive webgl game some day :>
  252. # [02:38] <aho> or well... some real game would be cool for starters
  253. # [02:38] <aho> ;)
  254. # [02:39] <aho> (the quake one doesnt count)
  255. # [02:39] <potatis_invalido> Damn it
  256. # [02:39] <potatis_invalido> I was just going to mention that
  257. # [02:40] <potatis_invalido> Yes, I'd like that too
  258. # [02:41] <potatis_invalido> JavaScript will probably have to get a little faster first though.
  259. # [02:42] <potatis_invalido> But if we give it a few years I'm sure something will pop up
  260. # [02:44] * Quits: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net) (Quit: Leaving.)
  261. # [02:45] <aho> speed is ok-ish nowadays, methinks
  262. # [02:46] <aho> full screen is still missing (right?)
  263. # [02:46] <aho> and mouse grabbing, too
  264. # [02:46] <aho> also, audio is very lacking
  265. # [02:47] <potatis_invalido> I agree about the first three
  266. # [02:47] <potatis_invalido> but audio?
  267. # [02:48] <zewt> there was some talk recently about getting started on a fullscreen API, but most of the talk was "which WG to do it in"; I don't know if that went anywhere
  268. # [02:48] <potatis_invalido> 3D audio might be a problem, now that I think of it
  269. # [02:48] <zewt> critical for <video> and games
  270. # [02:48] <potatis_invalido> position audio.
  271. # [02:48] <potatis_invalido> positional*
  272. # [02:49] <zewt> well, there's no API designed for game-audio
  273. # [02:49] <potatis_invalido> for simple audio you can just create a bunch of audio elements
  274. # [02:51] <potatis_invalido> HTML and related technologies are becoming more and more like traditional program environments
  275. # [02:51] <zewt> a full audio API is fairly complex, once you start getting into it (eg. positioning is just one part of environmental audio)
  276. # [02:51] <potatis_invalido> like Java and .NET
  277. # [02:52] * Quits: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1) (Ping timeout: 248 seconds)
  278. # [02:52] <aho> there isn't even panning :)
  279. # [02:52] <potatis_invalido> So I don't think it's entirely unlikely we'd see a 3D audio API in this decade.
  280. # [02:52] <potatis_invalido> we'll*
  281. # [02:52] <zewt> also a tough topic: accurate sync
  282. # [02:53] <aho> there are also some issues with current implementations. typically there is too much latency and chrome is the worst offender... it goes silent after a few minutes :v
  283. # [02:53] * Quits: dbaron (~dbaron@nat/mozilla/x-dpqheamnhurfgmrj) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  284. # [02:53] <zewt> my work has been on music games for years, so i know some of the headaches involved with audio sync :P
  285. # [02:57] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe) (Read error: Connection reset by peer)
  286. # [02:57] * Joins: amrith (~quassel@110.225.65.124)
  287. # [02:59] <potatis_invalido> Its's always something, isn't it? Remember that people once were impressed by Pong. :)
  288. # [03:00] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  289. # [03:01] <aho> opera does indeed not bother with caching that xhr thing
  290. # [03:01] <zewt> http://www.youtube.com/watch?v=T3BMqt00z9Y <- that's what I do (... no, that's not me); I don't have any hope of ever being able to make that sort of game in a web app :|
  291. # [03:01] <aho> even though the header says it expires in 2 years :I
  292. # [03:02] <zewt> audio apis tend to not give enough attention to sync, so making a game that depends on sub-10ms play-position accuracy is tricky
  293. # [03:02] * Quits: Duke___ (~Duke@187.50.13.57) (Remote host closed the connection)
  294. # [03:04] * Quits: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net) (Quit: xbuzz_)
  295. # [03:05] <zewt> aho: go nag some opera devs, i hate that too :P
  296. # [03:06] <zewt> don't know off-hand if it's the only browser that does that
  297. # [03:09] * Quits: agektmr (~Adium@nat/google/x-pxvxxhoedbbcsoki) (Quit: Leaving.)
  298. # [03:09] <zewt> it's particularly odd, since opera is generally more aggressive about caching than other browsers--not more conservative
  299. # [03:10] <zewt> (and there's no way they don't know about it)
  300. # [03:13] <aho> just cross-checked with fiddler... it really does request the file anew
  301. # [03:16] * Quits: mdelaney-afk (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Remote host closed the connection)
  302. # [03:17] * Joins: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
  303. # [03:18] <aho> http://www.stevesouders.com/blog/2009/08/11/f5-and-xhr-deep-dive/
  304. # [03:18] <aho> according to that expires in the future should be enough
  305. # [03:19] <zewt> i remember not being able to get data cached at all--but it's been a while and I'm not sure which browser I was having trouble with
  306. # [03:19] <zewt> it may have been some browser always revalidating even when told not to
  307. # [03:19] <zewt> (which is a lesser crime but still very bad, forcing a round-trip)
  308. # [03:21] <zewt> (let me know if you confirm expire/opera, btw, curious)
  309. # [03:21] * Quits: erlehmann (~erlehmann@82.113.99.33) (Quit: Ex-Chat)
  310. # [03:22] * Quits: dirkpennings (~Vuurbal@90-145-26-140.bbserv.nl)
  311. # [03:22] * Quits: jacobolus (~jacobolus@pool-74-104-110-147.bstnma.east.verizon.net) (Read error: Connection reset by peer)
  312. # [03:23] * Quits: ap (~ap@17.203.15.167) (Quit: ap)
  313. # [03:24] <potatis_invalido> I'm calling it a night. It was nice talking to you.
  314. # [03:24] <aho> nn
  315. # [03:24] <aho> well, as i said i already use expires headers (2 years in the future) and it doesn't cache anything
  316. # [03:24] * Joins: jacobolus (~jacobolus@pool-74-104-110-147.bstnma.east.verizon.net)
  317. # [03:24] <aho> same thing with his test case
  318. # [03:25] <aho> (he talks about opera 10 though. i'm using 11.)
  319. # [03:25] <Hixie> nessy: yt?
  320. # [03:25] <Hixie> foolip: yt?
  321. # [03:25] <zewt> could also be one of the other 92 cache-related headers
  322. # [03:25] <Hixie> doublec: yt?
  323. # [03:25] <doublec> Hixie: yep
  324. # [03:25] * Parts: potatis_invalido (~chatzilla@78-69-155-129-no176.tbcn.telia.com)
  325. # [03:26] <Hixie> doublec: so i'm looking at how to make MediaController work better based on the feedback so far
  326. # [03:26] <Hixie> doublec: dunno how much you've been following that
  327. # [03:26] <Hixie> doublec: (that's the multiple-synchronised-video/audio thing)
  328. # [03:26] <doublec> Hixie: Unfortunately I haven't had a chance to look at that yet
  329. # [03:26] <aho> http://pastebin.com/srkSQ2dk <- looks fine to me :f
  330. # [03:27] <aho> ehm
  331. # [03:27] <aho> wrong one
  332. # [03:27] <aho> :>
  333. # [03:27] <Hixie> doublec: k. well, quick overview: basically, it proposes an object that a <video> or <audio> element can be slaved to
  334. # [03:27] <Hixie> doublec: and all the slaved elements are forced to play at the same rate, and stall at the same time if any of them stall for network buffering, etc
  335. # [03:28] <aho> http://pastebin.com/KuBUSdJ1
  336. # [03:29] <Hixie> doublec: one thing my original proposal supported somewhat accidentally due to the way it was written is that if any of the media elements were set to loop, it would act as if the looping track was copied many times over infinitely in both directions -- think like a drum beat or metronome loop playing over a song
  337. # [03:29] <Hixie> doublec: based on feedback, i'm changing the api a bit to have the controlling object have a known duration, which of course doesn't work so well if any of the subtracks are looping
  338. # [03:30] <Hixie> doublec: i'm curious as to whether you have any suggestions on that front
  339. # [03:30] <Hixie> doublec: i'm thinking of basically making the looping tracks "fill" any time required to get them to fit the length of the longest non-repeating track
  340. # [03:31] <Hixie> doublec: kinda like a repeating background image
  341. # [03:32] <doublec> Hixie: we've got a Mozilla all hands next week where I'd like to gather the mozilla interested parties to discuss the api
  342. # [03:32] <doublec> Hixie: and then provide feedback
  343. # [03:33] <Hixie> doublec: in that case you should definitely let the htmlwg chairs know your timeline because they are saying we have to be done with proposals by this friday :-/
  344. # [03:33] <Hixie> doublec: i've been trying to explain to them that that's crazy but with minimal success
  345. # [03:33] <doublec> Hixie: that is crazy
  346. # [03:33] <zewt> are the chairs people, or are they actually like, lawn chairs
  347. # [03:33] <doublec> Hixie: is there a public-html thread about the deadline?
  348. # [03:33] <zewt> from people's opinions of them in here I'm no longer certain
  349. # [03:34] <Hixie> doublec: yeah. one minute, brb and can get it for you.
  350. # [03:34] * Joins: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net)
  351. # [03:35] <jamesr> Hixie: can't you just punt this all from html5 so the htmlwg doesn't care?
  352. # [03:36] * Quits: cying (~cying@173-13-176-101-sfba.hfc.comcastbusiness.net) (Quit: cying)
  353. # [03:38] <othermaciej> doublec: the deadline is effectively imposed by the LC deadline - we could punt the issue past Last Call, but currently Adrian Bateman has objected to that course of action
  354. # [03:38] <Hixie> jamesr: i did punt it from html5. then someone escalated it and now the chairs are insisting it must be done before their arbitrary last call deadline.
  355. # [03:38] <othermaciej> he suggested an extra week instead
  356. # [03:39] <othermaciej> it might be possible to give a one-week extension without blowing the LC deadline
  357. # [03:39] <othermaciej> I'm also not at all against postponing the issue if there is consensus to do that
  358. # [03:39] <jamesr> with the idea that designing an API in one week will produce a better result than waiting for it to be actually good?
  359. # [03:39] <othermaciej> I'm not sure why Adrian asked for the issue to be resolved in the very short time before Last Call
  360. # [03:40] <othermaciej> but folks should feel free to ask him
  361. # [03:40] <othermaciej> well, there's several API designs now which I think took more than a week each to create
  362. # [03:40] <othermaciej> I think it's a matter of refining them and seeing if differences can be eliminated
  363. # [03:40] <Hixie> i like how one vendor, who btw isn't going to ship anything for years given their ship cycle, is able to force an issue to be resolved in a few weeks but when we ask them for input we get nothing for months
  364. # [03:40] <Hixie> othermaciej, jamesr: any opinion on the thing above btw?
  365. # [03:40] <jamesr> i'm not familiar enough with media issues to comment intelligently
  366. # [03:41] <Hixie> othermaciej: consensus isn't the best way to make decisions
  367. # [03:41] <Hixie> othermaciej: also, why do we need consensus on postponing but not consensus on rushing?
  368. # [03:43] <doublec> I'd rather not include it at all than rush an api
  369. # [03:43] <othermaciej> Hixie: after reading the discussion thread, I kind of think the MediaController thing is ill-conceived - it's there in theory to avoid media elements having different master and slave modes, but in implementation terms, they have to have modes anyway
  370. # [03:43] <othermaciej> Hixie: and it results in an API that can't deliver what it promises
  371. # [03:43] * Joins: xbuzz__ (~chris@c-24-63-24-211.hsd1.ma.comcast.net)
  372. # [03:43] * Quits: xbuzz__ (~chris@c-24-63-24-211.hsd1.ma.comcast.net) (Client Quit)
  373. # [03:44] <Hixie> othermaciej: it's there to avoid making the api asymetric
  374. # [03:44] <othermaciej> Hixie: so it seems like it's prioritizing purity over implementations
  375. # [03:44] <Hixie> othermaciej: it's prioritising for authors.
  376. # [03:44] <othermaciej> (I don't think it's a benefit to authors to give them an API that doesn't work)
  377. # [03:44] <Hixie> why would it not work?
  378. # [03:44] <Hixie> or rather what doesn't work?
  379. # [03:44] <othermaciej> well, I'm imagining how we'd change our built-in controls to work with this API
  380. # [03:45] <othermaciej> they'd have to basically always talk to the controller object and never use the API directly on video
  381. # [03:45] <Hixie> same as with all the other proposals
  382. # [03:45] <othermaciej> and without a master/slave relationship, there wouldn't even be an easy way to have a different set of controls for the auxiliary tracks
  383. # [03:45] <Hixie> do you have an example of what you mean?
  384. # [03:45] <othermaciej> I imagine this is true of most set of JS-authored controls that want to work generically, and not just for one page
  385. # [03:45] <Hixie> what's an auxiliary track?
  386. # [03:46] <othermaciej> for example, a sign language translation that displays in a separate area
  387. # [03:46] <othermaciej> it might be that there are use cases where there isn't one clear "main" display area, but in the accessibility use cases, there generally is
  388. # [03:47] <Hixie> if there are two video playback areas, one with "content" and one with "sign language", what controls do you expect to see on the two elements?
  389. # [03:47] <Hixie> the two areas, i mean
  390. # [03:47] <othermaciej> I'd expect the content one to have full controls that control the master timeline
  391. # [03:48] <othermaciej> I would expect the sign language track to have either the same, or possibly to have reduced controls that don't actually manipulate the timeline, to reduce confusion/complexity
  392. # [03:48] <othermaciej> I don't know what our UI people would prefer
  393. # [03:48] <othermaciej> also we might hack the built-in fullscreen control to try to take the whole synchronized group full screen
  394. # [03:48] <othermaciej> though I dunno exactly how we'd do that
  395. # [03:48] <Hixie> none of this sounds hard with the MediaController API
  396. # [03:49] <othermaciej> it's not especially hard, but it's not easier either
  397. # [03:49] <othermaciej> the APIs on individual media elements would basically turn into an obscure thing that you should almost never use
  398. # [03:49] <Hixie> same as if they're asymetric
  399. # [03:49] <Hixie> except for one of the elements
  400. # [03:49] <Hixie> where they'd be serving two purposes
  401. # [03:49] <othermaciej> (does the MediaController API let you designate one media element as the lead, and others as auxiliary?)
  402. # [03:50] <Hixie> it could
  403. # [03:50] <Hixie> doesn't currently
  404. # [03:50] <othermaciej> I think when elements are synchronized, then probably all of their APIs should control the master timeline
  405. # [03:50] <Hixie> in most cases there isn't a lead, as fdar as i can tell
  406. # [03:50] <othermaciej> it's probably true that for non-accessibility use cases, there isn't necessarily a lead
  407. # [03:51] <othermaciej> anyway, I don't like rushing the design of this either :-(
  408. # [03:51] <othermaciej> and I have to get food while there's still time
  409. # [03:51] <othermaciej> brb
  410. # [03:53] * Joins: roc (~chatzilla@203-97-204-82.dsl.clear.net.nz)
  411. # [03:57] <nessy> Hixie: here
  412. # [03:58] <Hixie> nessy: trying to work out how to deal with looping of tracks in a multitrack situation, especially when the looping track is not the same length as the other tracks
  413. # [03:58] <Hixie> nessy: any ideas?
  414. # [03:58] * nessy reading up on discussion about .. gimme a sec
  415. # [04:03] * nessy ok..
  416. # [04:03] <nessy> so, it's all about what we want to see in the UI, I guess
  417. # [04:04] <Hixie> i doubt most cases with looping would have a ui
  418. # [04:04] <nessy> do we want individual slave tracks to have their own controls (API and displayed)?
  419. # [04:04] <Hixie> it's more about what cases might need looping
  420. # [04:04] <nessy> if it was for me, I'd disable individual looping
  421. # [04:04] <Hixie> most looping is likely to be used in things like games
  422. # [04:04] <nessy> in fact, all the functions that access the timeline, I would slave them together
  423. # [04:05] <zewt> is there really any practical use for looping except to loop an entire, combined media?
  424. # [04:05] <zewt> (eg. all tracks or none)
  425. # [04:05] <nessy> what zewt says...
  426. # [04:05] <zewt> the "metronome" thing is pretty contrived
  427. # [04:05] <nessy> what's your game use case?
  428. # [04:06] <Hixie> games use audio for all kinds of things
  429. # [04:06] <zewt> game audio is way beyond <audio> anyway
  430. # [04:06] <Hixie> e.g. background fire effects when you're in a room with a fire
  431. # [04:06] <Hixie> music
  432. # [04:06] <Hixie> explosions
  433. # [04:06] <nessy> the model I have in mind for multitrack is basically to replicate for external files what in-band would do - I don't think there is any in-band use for looping individual tracks
  434. # [04:07] <Hixie> have you ever used garage band?
  435. # [04:07] * Quits: jacobolus (~jacobolus@pool-74-104-110-147.bstnma.east.verizon.net) (Remote host closed the connection)
  436. # [04:07] <zewt> (my audio engine allows beat-matching two looping music tracks to seamlessly switch from one to another; rather beyond anything current APIs would try to do, heh)
  437. # [04:07] <nessy> yeah, but this is not an API to create a drum machine or music tracks
  438. # [04:07] <Hixie> we'd probably want a better api for something like garage band, but for simpler cases of things like that it might make sense to just use audio
  439. # [04:07] <nessy> I'd want that problem to be solved by an audio API
  440. # [04:08] <Hixie> for the whole app, sure
  441. # [04:08] <nessy> or asked otherwise: would somebody that wants to implement a game or a drum machine really want to use a multitrack media resource approach?
  442. # [04:08] <zewt> imo, trying to address game use cases with <audio> without actually expanding it to be a full-blown sound engine API ... feels like design creep
  443. # [04:08] <Hixie> what i'm saying is that smaller-scale parts of that might well be simple enough that people would just use <audio> for it
  444. # [04:09] * Joins: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  445. # [04:09] <nessy> they wouldn't use in-band mutltirack, certainly, so why try to bend external multitrack to support it?
  446. # [04:09] <Hixie> it's not about bending external multitrack
  447. # [04:10] <Hixie> given an external controller, these abilities just fall out if we do it right. the question is what is the right way to do it.
  448. # [04:10] <nessy> well, it creates a set of problems that I don't think we want to address in multitrack
  449. # [04:11] <Hixie> what problems?
  450. # [04:11] <nessy> such as independent looping, such as defining the duration, such as what happens with indpendent startOffset and with changes to playbackRate
  451. # [04:11] <Hixie> those aren't problems
  452. # [04:11] <nessy> what would be the duration of a multitrack resource that has a looping track?
  453. # [04:11] <Hixie> those are things we have to define anyway
  454. # [04:11] <Hixie> we can define them as "they do nothing" or we can provide a useful definition
  455. # [04:11] <Hixie> but either way we have taoaddress them
  456. # [04:12] <nessy> no, if we don't accept looping on an individual track, the duration of the overall composition is easier to determine
  457. # [04:12] <nessy> the problem space is smaller
  458. # [04:12] <Hixie> if you decide something, then the number of things you have to decide is smaller, yes
  459. # [04:12] <roc> I hear we need to give feedback by Friday
  460. # [04:12] <nessy> hi roc!
  461. # [04:12] <Hixie> but the number of things you have to decide in all is still the same
  462. # [04:13] <roc> what's up with that? We can't give decent feedback until we've implemented it, and believe it or not we won't have it implemented by Friday
  463. # [04:13] <Hixie> oh, that reminds me, i had to get a url for doublec
  464. # [04:13] <roc> nessy: hi
  465. # [04:13] <nessy> yeah, do write an email on the list that you also want more time to give feedback
  466. # [04:13] <zewt> FWIW, I'd have a duration *assigned* to looping tracks individually (which might be "infinite" if the user wants to loop forever); tracks loop for as long as they're told to; and the duration of the composition of many tracks is straightforward: the maximum duration of all tracks
  467. # [04:13] <nessy> I've already stated that multiple times
  468. # [04:14] <roc> which list?
  469. # [04:14] <roc> public-html?
  470. # [04:14] <nessy> yes
  471. # [04:14] <nessy> reply to Adrian's message I would say
  472. # [04:14] <Hixie> doublec, roc: http://lists.w3.org/Archives/Public/public-html-a11y/2011Mar/0214.html
  473. # [04:15] <nessy> search for "Timing of ISSUE-152"
  474. # [04:15] <Hixie> http://lists.w3.org/Archives/Public/public-html/2011Mar/0746.html is adrian's e-mail
  475. # [04:15] <nessy> well, the first one is on the a11y list and thus more an internal discussion, IMHO
  476. # [04:15] <nessy> yeah, that second one
  477. # [04:15] <Hixie> "internal"?
  478. # [04:16] <nessy> well, TF-internal discussion to at least get agreement within the TF
  479. # [04:16] * Parts: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  480. # [04:17] <Hixie> agreement within the TF means nothing except that it's harder to discuss the issue once it goes to the whole group since the people in the TF are invested in their agreement :-)
  481. # [04:17] * Hixie thinks the TFs are a bad idea, but that's probably old news
  482. # [04:17] <nessy> yes, that's why I am saying the one on the main list is more important
  483. # [04:17] <nessy> btw: there's not necessarily agreement in the TF even when things are moved forward
  484. # [04:17] <nessy> anyway...
  485. # [04:20] <nessy> what is the duration of a composition that contains a looping track?
  486. # [04:20] <Hixie> that is one of the questions we'd have to answer if we decide looping is to be supported
  487. # [04:20] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  488. # [04:20] <nessy> would it play until all non-loping tracks have completed their duration and then just continue with the looping track?
  489. # [04:21] <nessy> to be honest, I think it's an artificial use case - a solution looking for a problem
  490. # [04:21] <zewt> it seems it's hard to decide what to do because there are no use cases to base a design on :)
  491. # [04:22] <Hixie> it's not a use case, it's not a solution -- it's just something we have to decide one way or the other
  492. # [04:22] <Hixie> nessy: it's like saying that the ability to put a span inside an em inside a dfn is an artificial use case or a solution looking for a problem
  493. # [04:22] <nessy> what things to you intend to lock into sync between the slave elements?
  494. # [04:23] * Quits: miketaylr (~miketaylr@user-160vrg5.cable.mindspring.com) (Quit: miketaylr)
  495. # [04:23] <Hixie> based on feedback so far, playback rate
  496. # [04:24] <nessy> also currentTime progress when playing, I guess
  497. # [04:24] <Hixie> how do you mean?
  498. # [04:25] <nessy> well, when you start playing one, you should start playing them all (as far as they are set to display), right?
  499. # [04:25] <Hixie> that's the playback rate :-)
  500. # [04:25] * Quits: othermaciej (~mjs@17.246.16.190) (Quit: othermaciej)
  501. # [04:26] <nessy> how do you jump to the same time offset across all of them?
  502. # [04:26] <nessy> from script
  503. # [04:26] <nessy> so you can make a common controller for all of them
  504. # [04:26] <roc> Hixie: I have a feeling that solutions for multiple-media-resource synchronization, advanced audio API and RTC all need to be solved in an integrated way
  505. # [04:26] * Quits: bentruyman (~bentruyma@24-148-24-69.c3-0.prs-ubr2.chi-prs.il.cable.rcn.com) (Quit: bentruyman)
  506. # [04:26] <roc> right now I think we have three trains rushing towards each other at high speed
  507. # [04:27] * Quits: estes (~aestes@17.203.13.46) (Quit: estes)
  508. # [04:27] <Hixie> nessy: based on your feedback i'm planning on providing a currentTime feature in the MediaController to replace the seek() feature (that's why the looping thing became an issue -- it wasn't an issue at all with the old seek() approach, which is why i'd gone with seek() rather than a currentTime approach)
  509. # [04:27] <nessy> lol: want to add a fourth train? HTTP adaptive streaming
  510. # [04:27] <nessy> Hixie: I see - that explains it
  511. # [04:27] <Hixie> roc: the RTC and multiple-track things are definitely coordinated, at least insofar as I'm working on them
  512. # [04:28] <Hixie> roc: in fact they currently share an interface (the TrackList thing)
  513. # [04:28] <roc> yeah
  514. # [04:28] <nessy> oh really? … I need to check that...
  515. # [04:29] <Hixie> roc: (that's one reason i'm hoping to make the MediaController thing be good enough to convince silvia and others, so that they are coordinated, since the other proposals aren't coordinated like that)
  516. # [04:29] <roc> but the audio API piece is very significant
  517. # [04:29] <Hixie> roc: agreed
  518. # [04:29] <Hixie> roc: i need to coordinate with them more
  519. # [04:29] <roc> audio API needs to sync multiple streams
  520. # [04:29] <roc> with processing
  521. # [04:29] <Hixie> unfortunately they went to hide into an xg of their own :-P
  522. # [04:29] <Hixie> bbiab
  523. # [04:30] <roc> audio API needs to integrate with RTC to enable big use cases like XBox 360's voice distortion
  524. # [04:30] <roc> er, XBox Live
  525. # [04:31] * Quits: kennyluck (~kennyluck@netDHCP-169.keio.w3.org) (Quit: kennyluck)
  526. # [04:31] * Joins: othermaciej (~mjs@67.218.107.17)
  527. # [04:32] <nessy> roc: do write about that to public-html, too - maybe that makes Adrian change his mind
  528. # [04:33] <roc> message already sent
  529. # [04:34] <karlcow> http://httparchive.org/interesting.php
  530. # [04:34] <nessy> in real-time communication - do we really need to lock the local and remote video stream to each other via a controller?
  531. # [04:34] <roc> you can't
  532. # [04:34] <nessy> I mean: skype doesn't do that - it just displays the data that it gets as quickly as possible
  533. # [04:35] <roc> who says we should do that?
  534. # [04:35] <karlcow> 28% of Web pages with Error.
  535. # [04:35] <nessy> ok, cool - I need to find out what we need tracks for RTC then...
  536. # [04:35] <karlcow> or more exactly 28% of URIs with HTTP errors
  537. # [04:36] <karlcow> 61% with HTTP redirects
  538. # [04:36] <nessy> (I've not read up on the RTC proposal yet)
  539. # [04:36] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Read error: Operation timed out)
  540. # [04:36] * Parts: tw2113 (~tw2113@fedora/tw2113) ("IRC is just multiplayer notepad")
  541. # [04:36] <nessy> http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html#generatedstream
  542. # [04:36] * Joins: ojan (~ojan@74.125.56.17)
  543. # [04:37] <nessy> ok, there is no controller there, just the track lists
  544. # [04:38] * Joins: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net)
  545. # [04:39] <roc> I think the tracklist stuff is low-hanging fruit
  546. # [04:39] <roc> we could just add that to media elements without any of the MediaController stuff, relatively easy to implement and addresses some important use cases
  547. # [04:39] <roc> that seems uncontroversial to me
  548. # [04:41] <othermaciej> Hixie: so, let me elaborate my prior use case a it more
  549. # [04:41] <othermaciej> Hixie: let's say I have a site that embeds various videos
  550. # [04:41] * Quits: jwalden (~waldo@63.224.145.184) (Ping timeout: 276 seconds)
  551. # [04:41] <othermaciej> I use an existing JS library to provide custom branded controls
  552. # [04:42] * Quits: amrith (~quassel@110.225.65.124) (Remote host closed the connection)
  553. # [04:42] * Joins: jwalden (~waldo@63.224.145.184)
  554. # [04:42] <othermaciej> this library is written to use the regular <video> API, not MediaController, since that is what it's historically used, and it generally works if you don't synchronize additional media items, so the developer never thought to change it
  555. # [04:43] <othermaciej> now for one video, I want to synch an external sign language translation video
  556. # [04:43] <othermaciej> in a separate playback area
  557. # [04:43] <othermaciej> it seems like my options are:
  558. # [04:43] <othermaciej> - rewrite the control logic
  559. # [04:43] <othermaciej> - switch to another JS library
  560. # [04:43] <othermaciej> - accept broken playback controls
  561. # [04:43] <othermaciej> that's kind of sucky
  562. # [04:43] <othermaciej> so there have to be strong use cases to justify the model that imposes this porting cost
  563. # [04:44] * Joins: jacobolus (~jacobolus@c-24-128-49-85.hsd1.ma.comcast.net)
  564. # [04:44] <othermaciej> now, one thing you could do is make the playback API on synch'd videos always throw, to force you to use the media controller, so at least that kind of bug is caught sooner
  565. # [04:45] <othermaciej> but that seems to remove the elegance and symmetry from the proposal
  566. # [04:46] * Quits: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Quit: tomasf)
  567. # [04:47] <othermaciej> (I think the Eric/Sylvia proposal will Just Work for that case if you don't want any controls on the slave track, which most likely you do not)
  568. # [04:48] <nessy> (note that I am not married to our proposal - I want this to be worked out properly and I am not yet sure what the best approach is - still experimenting)
  569. # [04:52] * ojan is now known as ojan_lunch
  570. # [04:53] * Joins: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  571. # [04:54] * Quits: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net) (Client Quit)
  572. # [04:56] <Hixie> othermaciej: if we had much legacy for <video>, i'd agree
  573. # [04:56] <Hixie> othermaciej: but we don't
  574. # [04:56] <Hixie> othermaciej: we can just treat this as part of the original api
  575. # [04:56] <Hixie> othermaciej: note that just using the Eric/Sylvia proposal wouldn't work either, if the slaved track was longer
  576. # [04:57] <Hixie> othermaciej: and it wouldn't work right if it assumed that the readyState of the main media element was representative of when the media could play
  577. # [04:57] <othermaciej> really? there's a lot of hosting sites using HTML5 video, and a lot of control libraries
  578. # [04:57] <Hixie> othermaciej: (since the other track might still be buffering)
  579. # [04:57] <othermaciej> I'm not down with (effectively) breaking compatibility with all current HTML5 video content
  580. # [04:57] <Hixie> othermaciej: this wouldn't break compat with anything, it just adds a new feature
  581. # [04:58] <othermaciej> sure, but if you use the feature, it breaks compat with any existing reusable video code you may have used
  582. # [04:58] <othermaciej> Eric/Sylvia proposal is easily extended to make the master media element proxy more things for the whole group
  583. # [04:58] <Hixie> othermaciej: the idea of reusing a media element as the master is a huge hack that will cause problems for years, imho
  584. # [04:59] <othermaciej> what kind of problems do you expect it to cause?
  585. # [05:00] <Hixie> othermaciej: it ties together the status for the whole group and the status for a single resource in such a way that you can't intuitively tell which you're looking at
  586. # [05:00] <Hixie> othermaciej: so e.g. we'll be stuck with not having tracks longer than the master track
  587. # [05:00] <Hixie> othermaciej: we'll be stuck with never having separate playback rate controls for individual tracks in a consistent way
  588. # [05:00] <othermaciej> if you make it only represent status for the whole group, we won't be stuck with such things
  589. # [05:00] <nessy> what is "working right for slaved tracks of different duration"? what do you expect should happen? it is possible to make that happen in any of the proposals IMHO
  590. # [05:00] <othermaciej> the timeline would be max of all timelines
  591. # [05:00] <Hixie> othermaciej: you wouldn't be able to mute the audio of just the master track
  592. # [05:01] <Hixie> othermaciej: you wouldn't be able to seek just the master track
  593. # [05:01] <Hixie> othermaciej: the list goes on and on and on
  594. # [05:01] <othermaciej> separate playback rate controls for individual tracks doesn't really have much of a use case
  595. # [05:01] <othermaciej> your suggested use cases do not seem realistic or useful as reviewed by media experts
  596. # [05:01] <Hixie> it's just an example of something we get blocked out of
  597. # [05:02] <Hixie> anything that relies on the api to control an individual track as opposed to the group is screwed
  598. # [05:02] <othermaciej> seeking just the master track also seems useless
  599. # [05:02] <Hixie> nessy: either the master's video.duration is the resource's duration (in which case you lose the ability to see the group's) or it's the group's (in which case you lose the ability to see the resource's)
  600. # [05:02] <othermaciej> well, if we ever have real use cases for and practical implementability of individual playback control of sync'd tracks, we can add new API for that
  601. # [05:03] <Hixie> othermaciej: you keep dismissing abilities as having no use cases but the whole point is to have a simple api that enables any use case
  602. # [05:03] <othermaciej> right now, there aren't good use cases, and it's not practical to implement
  603. # [05:03] <othermaciej> Hixie: you sound like an RDF guy right now
  604. # [05:03] <Hixie> hah
  605. # [05:03] <Hixie> based on what Jer was saying, it's quite feasible to implement a MediaController approach
  606. # [05:03] <nessy> I'm not opposed to a MediaController approach either
  607. # [05:04] <nessy> I think we have to solve the same problems for all of the proposals, btw
  608. # [05:04] <othermaciej> it is, it will just have severe limitations that make the edge case use cases not really work
  609. # [05:04] <othermaciej> and it will break compat with existing controller code if you ever use syncing
  610. # [05:04] <Hixie> what severe limitations?
  611. # [05:04] * Joins: bentruyman (~bentruyma@24-148-24-69.c3-0.prs-ubr2.chi-prs.il.cable.rcn.com)
  612. # [05:04] <othermaciej> and poor performance if you don't hit the sweet spot
  613. # [05:05] <Hixie> so would the other proposal
  614. # [05:05] * Joins: f1lt3r_bocoup (~f1lt3r@75-150-66-249-NewEngland.hfc.comcastbusiness.net)
  615. # [05:05] <Hixie> and the existing controllers don't just work with the asymetric proposal either
  616. # [05:05] <othermaciej> you can't actually control playback of the individual tracks separately live
  617. # [05:06] <Hixie> the asymetric proposal allows that too, to the same extent (except that you can't do the master track for a random reason)
  618. # [05:06] <nessy> the master is not independent of its slaves, that's right
  619. # [05:06] <Hixie> so it would have the same "severe limitation"
  620. # [05:06] <Hixie> (or as i would put it, and as jer put it, "quality of implementation issue")
  621. # [05:07] * Quits: f1lt3r_bocoup (~f1lt3r@75-150-66-249-NewEngland.hfc.comcastbusiness.net) (Client Quit)
  622. # [05:07] * Joins: F1LT3R (~f1lt3r@75-150-66-249-NewEngland.hfc.comcastbusiness.net)
  623. # [05:07] <Hixie> othermaciej: the difference between this and rdf is that in this case, we get the various abilities and a consistent api by having a _simpler_ solution
  624. # [05:07] <othermaciej> sure, but if every implementation is going to have a QoI issue that makes a feature not practical to use, it's not helpful to say it's just a QoI issue
  625. # [05:07] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
  626. # [05:07] <nessy> my main objection is whether it can be implemented, since the controller basically has its own independent timeline
  627. # [05:07] <Hixie> othermaciej: so should we not support seeking in the current api either?
  628. # [05:08] <othermaciej> I think it's debatable whether adding new API or making existing API modal is simpler
  629. # [05:08] <Hixie> othermaciej: or playbackRate?
  630. # [05:08] <nessy> however, we could always assume that the first element that is slaved to the controller is the main one to define the timeline from a sw implementation pov
  631. # [05:08] <Hixie> the video api is full of things that have QoI issues
  632. # [05:08] <Hixie> nessy: what do you mean by "timeline"?
  633. # [05:09] <nessy> clock
  634. # [05:09] <Hixie> nessy: the MediaController spec already defines that
  635. # [05:09] <nessy> it drives the playbackRate of all the slaves
  636. # [05:09] <nessy> so, it needs to have a clock
  637. # [05:09] <Hixie> "All the slaved media elements of a MediaController must use the same clock for their definition of their media timeline's unit time."
  638. # [05:09] <nessy> and in all media frameworks that I know, there is no such thing as an abstract clock - it's always bound to a specific resource
  639. # [05:10] <Hixie> no need to define which one it is, since it doesn't matter which one it is so long as there is only noe
  640. # [05:10] <nessy> (I'm talking implementation, not definition)
  641. # [05:10] <Hixie> one
  642. # [05:10] <Hixie> ah ok
  643. # [05:10] <Hixie> i don't see the problem then
  644. # [05:11] <Hixie> why would it be any different to implement?
  645. # [05:11] <nessy> yeah, all I am saying is that it's probably a hack to get it implemented and not as clean as it might seem
  646. # [05:11] <nessy> i.e. if you happen to remove during playback the one element that defines the timeline, all sorts of things may go wrong
  647. # [05:12] <Hixie> if you remove anything during playback, you need to redo the group anyway
  648. # [05:12] <Hixie> according to jer
  649. # [05:12] <Hixie> so that's rather academic
  650. # [05:12] <Hixie> also, you can do that with your proposal too :-)
  651. # [05:12] <nessy> you could remove any slave without affecting the timeline
  652. # [05:12] <nessy> removing the master is kinda dumb
  653. # [05:13] <Hixie> removing a slave, according to jer, will cause stalling
  654. # [05:13] <nessy> when you have a controller, yes, because you may need to find another element to become the timeline master
  655. # [05:13] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Quit: davidwalsh)
  656. # [05:13] <Hixie> no, in general
  657. # [05:13] <Hixie> not because of the controller
  658. # [05:13] <nessy> I don't thinks - that's not how I interpreted Jer's feedback
  659. # [05:14] <nessy> s/thinks/think so/
  660. # [05:14] <Hixie> ah, correction, he was talking about adding tracks
  661. # [05:14] <Hixie> in any case, what's the use case for every adding or removing tracks on the fly?
  662. # [05:14] <nessy> yeah, I guess hooking that into the master or controller would take time
  663. # [05:15] <Hixie> it seems like a rare event, so i don't see much point worrying about it
  664. # [05:15] <Hixie> and since both proposals have the problem, it seems academic
  665. # [05:15] <nessy> not at all - what if you are playing a video and mid-video you turn on the audio description track?
  666. # [05:15] <Hixie> it would already be slaved
  667. # [05:15] <nessy> I think that use case is more common than looping ;-)
  668. # [05:15] <Hixie> just disabled
  669. # [05:16] <Hixie> looping of synced content isn't common at all as far as i'm aware
  670. # [05:16] <nessy> disabled tracks aren't loaded and thus aren't progressing in time
  671. # [05:16] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Ping timeout: 260 seconds)
  672. # [05:16] <Hixie> they can be
  673. # [05:16] <Hixie> they certainly will be loaded
  674. # [05:16] <nessy> (agree on the looping - I can't think of having seen that anywhere)
  675. # [05:17] <Hixie> my point is just that the problem exists with all the proposals
  676. # [05:17] <nessy> why would you load a resource that you're not using?
  677. # [05:17] <Hixie> because you might use it
  678. # [05:17] <Hixie> that's what prefetching is all about
  679. # [05:18] <nessy> yes, but in this case prefetching doesn't make much sense for disabled tracks
  680. # [05:18] <nessy> in particular if you have a video with 52 dubbed audio tracks where you only want to play one
  681. # [05:18] <Hixie> *shrug* sure, the author would say which to prefetch
  682. # [05:20] <nessy> all I am saying is that in my understanding the implementation would be a hack that would probably decide on a master video or audio anyway
  683. # [05:20] <nessy> this does not mean, however, that we have to define the html markup and api in that way
  684. # [05:20] <Hixie> i'm not sure i understand your use of the word "hack", but ok
  685. # [05:21] * Quits: othermaciej (~mjs@67.218.107.17) (Quit: othermaciej)
  686. # [05:22] <nessy> a "hack" in that the concept that is defined in the controller as a clock that applies to all elements would in the implementation mean to clock of one element to which the others are slaved
  687. # [05:22] <nessy> I can see advantages of the controller approach
  688. # [05:23] <Hixie> but the spec doesn't say the controller has a clock
  689. # [05:23] <Hixie> it says the slaved elements must have the same clock, that's all
  690. # [05:23] <nessy> I would almost feel compelled to give the controller a css rendering area of its own even, so we can use css to arrange all the slave elements into that box and provide a single transport bar over all of them
  691. # [05:24] <roc> I want to implement API to list and select in-band tracks in a single media element, and punt on the out-of-band stuff until we understand how RTC and advanced audio API fit in
  692. # [05:24] <Hixie> (in practice you have to use the clock of the sound card. in your proposal, what would happen if the master was silent and there were two slaved audio tracks? the UA would have to use the clock of one of the audio tracks.)
  693. # [05:24] * Quits: dave_levin (~dave_levi@nat/google/x-sgfkwznpagzxcehm) (Quit: dave_levin)
  694. # [05:24] <roc> if the master is silent you can pretend it has an audio track of all silence and mix the slaves into it
  695. # [05:24] <Hixie> roc: i had been hoping to punt the api for the same reason, but unfortunately nessy then escalated the issue which is how we ended up discussing it :-)
  696. # [05:25] <nessy> I did not escalate the issue - I've not ever escalated any issue!
  697. # [05:25] <Hixie> http://www.w3.org/html/wg/tracker/issues/152 says "This issue was raised on behalf of Silvia Pfeiffer"
  698. # [05:25] <nessy> but I certainly registered the bug
  699. # [05:26] <Hixie> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9452#c8 is where the TrackerRequest keyword was added, which indeed suggests otherwise
  700. # [05:27] * Quits: jamesr (~jamesr@216.239.45.19) (Quit: jamesr)
  701. # [05:30] * Joins: othermaciej (~mjs@c-24-6-209-6.hsd1.ca.comcast.net)
  702. # [05:34] <nessy> I guess it was just raised as part of the bugs that were registered pre last call
  703. # [05:34] <nessy> anyway...
  704. # [05:35] <nessy> what influence does RTC have on mutltirack?
  705. # [05:35] <Hixie> hard to know in advance
  706. # [05:35] <Hixie> in the current proposal they share the audioTracks and videoTracks attributes
  707. # [05:35] <Hixie> amongst other things
  708. # [05:35] <Hixie> (like both using <video>)
  709. # [05:35] <nessy> do you want to make use of the controller concept for rtc?
  710. # [05:36] <Hixie> i'm not currently aware of any reason to use MediaController in the context of video conferencing, but naturally we'd have to make sure how they interact is defined
  711. # [05:38] <nessy> or asked otherwise: why do you have a GeneratedStream API, when it is basically the same as the MediaController?
  712. # [05:38] <nessy> aren't they basically achieving the same thing?
  713. # [05:38] <nessy> (really trying to understand it - no criticism)
  714. # [05:40] <Hixie> i don't understand in what way they are similar :-)
  715. # [05:40] * Joins: MikeSmith (~MikeSmith@EM114-48-251-107.pool.e-mobile.ne.jp)
  716. # [05:40] <Hixie> they have nothing in common as far as i can tell
  717. # [05:41] <nessy> a controller synchronizes multiple audio and video streams - so does a generatedStream
  718. # [05:42] <Hixie> a generatedstream just exposes a local webcam
  719. # [05:42] <Hixie> it doesn't do synchronisation
  720. # [05:42] <Hixie> not in the sense that mediacontroller does
  721. # [05:42] <nessy> so the audio and video tracks inside it are not synchronized?
  722. # [05:42] <Hixie> they're one media stream
  723. # [05:43] <nessy> is the difference that the GeneratedStream is creating data, while the MediaController is playing back data?
  724. # [05:43] <Hixie> the mediacontroller doesn't play back data
  725. # [05:43] <Hixie> it just ensures a number of <video> elements have the same clock
  726. # [05:43] <Hixie> it's like saying a <video> is the same as a mediacontroller, which i think is equally non-sequitur, though i guess you are proposing that too :-)
  727. # [05:43] <nessy> … and they play them back in sync, so indirectly, it does that
  728. # [05:44] <nessy> a <video> has a controller, if you want it or not - it may not be exposed ;-)
  729. # [05:44] <Hixie> overloading objects to do many related things is bad api design
  730. # [05:45] <Hixie> one should just have one object per task
  731. # [05:45] <nessy> sure
  732. # [05:45] <Hixie> (video, in retrospect, is poorly designed because it amalgamates video fetch and video playback)
  733. # [05:45] <nessy> I'm trying to understand the difference ...
  734. # [05:45] <nessy> and if we say that there is a difference, then I also don't see a need to have one wait for the other to be defined
  735. # [05:47] <Hixie> things that interact need to be designed with each other in mind
  736. # [05:47] <Hixie> otherwise you end up with apis that look like, well, a lot of the web's apis
  737. # [05:47] <othermaciej> fair point; though there is also value to doing things incrementally
  738. # [05:47] <othermaciej> it is hard to strike the right balance
  739. # [05:47] <nessy> yeah, unfortunately, it is impossible to solve all the world's problems at the same time - you end up achieving nothing
  740. # [05:47] <Hixie> incrementally is fine too, but it risks getting things like the video element :-)
  741. # [05:48] <Hixie> nessy: what i often do in the whatwg spec is overdesign and then comment-out large parts of the feature
  742. # [05:48] <nessy> yeah, I learnt that recently - I was indeed curious!
  743. # [05:48] <Hixie> nessy: the (new) drag-and-drop api being one example, where the spec already has support for a number of things that aren't in the spec, like promises and file objects (or is it blob objects)
  744. # [05:49] <Hixie> or like automatic ducking in the multitrack feature
  745. # [05:49] <Hixie> which is in there but commented out
  746. # [05:49] <nessy> is there a way to view the spec will all your commented out things>
  747. # [05:49] <nessy> ?
  748. # [05:49] <Hixie> view > source :-)
  749. # [05:49] <nessy> lol
  750. # [05:50] <nessy> ok… I might browse the repository - I find that easier
  751. # [05:50] <Hixie> (though you're better off just looking at the /source file)
  752. # [05:50] <roc> Hixie: I think there could be an indirect relationship between RTC and multitrack
  753. # [05:50] <nessy> anyway - I am planning to try and design the multitrack with a conroller in mind, too, independently of what you did, and see where that takes me
  754. # [05:50] <nessy> … might end up having a clearer view of things then
  755. # [05:51] <nessy> roc: how so? do you have a hunch?
  756. # [05:51] <roc> Hixie's RTC proposal defines Streams which can be used as sources for media elements
  757. # [05:52] <roc> maybe that feature isn't literally in Hixie's draft, but it's clearly coming
  758. # [05:52] <Hixie> it's there
  759. # [05:52] <Hixie> there's even an example
  760. # [05:52] <roc> therefore multitrack synchronization needs to work with Streams
  761. # [05:52] <Hixie> search for "Snapshot Kiosk"
  762. # [05:53] <roc> furthermore
  763. # [05:53] <roc> if we define an advanced audio API based on Streams
  764. # [05:53] <roc> (including integrating existing audio API proposals with Streams)
  765. # [05:54] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Ping timeout: 248 seconds)
  766. # [05:54] * ojan_lunch is now known as ojan
  767. # [05:54] <roc> then that API will almost certainly allow mixing of multiple sources
  768. # [05:54] <roc> which will need to be synchronized
  769. # [05:54] * Quits: MikeSmith (~MikeSmith@EM114-48-251-107.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
  770. # [05:55] <roc> which creates considerable overlap with MediaController and related proposals
  771. # [05:55] <nessy> GeneratedStream is the thing that synchronizes them, right?
  772. # [05:55] <Hixie> GeneratedStream is just a representation of the local WebCam's output
  773. # [05:56] <Hixie> it doesn't synchronise anything
  774. # [05:56] <Hixie> you can think of it as a remote stream
  775. # [05:56] <Hixie> rtsp://whatever/foo
  776. # [05:57] <roc> in particular any advanced audio API is likely to need a way to get a Stream (or equivalent) representing an arbitrary media resource, and mix those Streams together in a synchronized way, optionally with effects
  777. # [05:58] <roc> at which point you almost have the functionality of a MediaController
  778. # [05:58] <roc> even if the APIs stay unrelated (I'm not sure if that's wise or not), the implementation probably should have much in common
  779. # [05:59] <roc> at least in Gecko, where we're not shackled by some media framework
  780. # [05:59] <roc> am I making sense?
  781. # [06:00] * Quits: bentruyman (~bentruyma@24-148-24-69.c3-0.prs-ubr2.chi-prs.il.cable.rcn.com) (Remote host closed the connection)
  782. # [06:03] <roc> I guess not :-)
  783. # [06:03] * nessy is thinking...
  784. # [06:04] <nessy> well, if the implementation shares a lot, that would not have much of an effect on the markup and API, I guess
  785. # [06:04] <Hixie> hmm...
  786. # [06:05] <nessy> I am trying to understand how the streams are synchronized in the rtc proposal
  787. # [06:07] * Quits: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net) (Quit: cying)
  788. # [06:07] <Hixie> having added a combined currentTime feature, i wonder whether to just force the slaved tracks to be aligned up and not support offsets at all
  789. # [06:07] <Hixie> since offsets would have to be implicit, which is confusing
  790. # [06:07] <Hixie> hmm
  791. # [06:08] * Hixie isn't liking the implications of having to add currentTime to the media controller
  792. # [06:08] <Hixie> nessy: nothing synchronises anything in the PeerConnection/GeneratedStream world
  793. # [06:08] <Hixie> nessy: there's nothing to synchronise
  794. # [06:09] <nessy> a local audio and video stream that are recorded and then sent to the other side would need to be synchronized to each other
  795. # [06:09] <Hixie> they're one stream
  796. # [06:09] <nessy> s/recorded/captured/
  797. # [06:10] <Hixie> that's like asking what synchronises the audio and video in a .mov file
  798. # [06:10] <Hixie> they're never _not_ synchronised
  799. # [06:10] <nessy> yes, and there is an answer: the container
  800. # [06:10] <Hixie> same answer applies here
  801. # [06:10] <nessy> are they being put in a container?
  802. # [06:11] <nessy> by the GeneratedStream object?
  803. # [06:11] <nessy> then it does the synchronization
  804. # [06:11] <Hixie> the user agent serialises them (with a container) as part of RTP
  805. # [06:11] <Hixie> (or as part of the StreamRecorder when recording to a file)
  806. # [06:12] <Hixie> this is an entirely different, and far less interesting, kind of synchronisation than what we're talking about with MediaController
  807. # [06:12] <nessy> anyway … more importantly your question before...
  808. # [06:13] <nessy> I would agree that we should not support offsets
  809. # [06:13] <Hixie> well we'd still support offsets, either now or eventually
  810. # [06:13] <Hixie> the question is when we do, what should the api look like
  811. # [06:13] <nessy> the by far most common use case for multitrack is same length audio and video tracks that all start at the same time and all end at roughly the same time
  812. # [06:14] <Hixie> that's a self-fulfilling prophecy if we design it to only truly cater for that use case
  813. # [06:15] <nessy> maybe there are two fundamentally different use cases that we are trying to satisfy with the same approach
  814. # [06:15] <Hixie> if we instead do as roc is suggesting, and design this with the audio api in mind, then "drum machines" as you call them (and more specifically, the audio synchronisation in video games) might well be far more common use cases
  815. # [06:16] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
  816. # [06:16] <Hixie> on the long run
  817. # [06:17] <Hixie> even if we don't support that, i think things like director's commentaries are going to be a major use case, and they're often not the same length as the video
  818. # [06:17] <nessy> they still start at the same time
  819. # [06:17] <Hixie> usually
  820. # [06:17] <Hixie> though often they're silent for a while at the start
  821. # [06:17] <nessy> overhang at the end is not as big a problem as different playback positions for each track
  822. # [06:17] <Hixie> different playback positions isn't a problem :-)
  823. # [06:18] <nessy> how do you create a common transport bar then?
  824. # [06:18] <Hixie> we can easily have the media controller define a zero point and a total duration that spans the earliest point to the latest point, taking offsets into account
  825. # [06:19] <zewt> for a commentary track that doesn't start immediately, that can probably be done by having a timestamp offset in the file itself, at authoring time to match the video track it's for--rather than setting it by hand in script
  826. # [06:19] <nessy> ok, then currentTime would be the time on that transport bar - where is the problem?
  827. # [06:19] <Hixie> nessy: you're the one who said there was a problem :-)
  828. # [06:20] <nessy> you said:
  829. # [06:20] <Hixie> zewt: yeah, that would be ideal
  830. # [06:20] <nessy> "having added a combined currentTime feature, i wonder whether to just force the slaved tracks to be aligned up and not support offsets at all
  831. # [06:20] <nessy> since offsets would have to be implicit, which is confusing"
  832. # [06:22] <Hixie> here's what i just wrote in the e-mail i'm writing in response to all the feedback:
  833. # [06:22] * Quits: weinig (~weinig@17.203.15.198) (Ping timeout: 252 seconds)
  834. # [06:22] <Hixie> Originally, the tracks could be offset because their .currentTime attributes were advanced at a fixed rate, and the MediaController didn't have any concept of the currentTime, so just changing the currentTime of a media element offset the video by the difference between the old and new values. I guess theoretically we can still do that, but it becomes kind of weird that you can change the currentTime of each video in
  835. # [06:23] <Hixie> oh that didn't wrap right
  836. # [06:23] <Hixie> second try:
  837. # [06:23] <Hixie> Originally, the tracks could be offset because their .currentTime
  838. # [06:23] <Hixie> attributes were advanced at a fixed rate, and the MediaController didn't
  839. # [06:23] <Hixie> have any concept of the currentTime, so just changing the currentTime of
  840. # [06:23] <Hixie> a media element offset the video by the difference between the old and
  841. # [06:23] <Hixie> new values.
  842. # [06:23] <Hixie> I guess theoretically we can still do that, but it becomes kind of weird
  843. # [06:23] <Hixie> that you can change the currentTime of each video in turn, and when you
  844. # [06:23] <Hixie> change the first one, the controller's "duration" changes, and then
  845. # [06:23] <Hixie> suddenly when you change the last slaved media elements's currentTime, the
  846. # [06:24] <Hixie> duration changes back.
  847. # [06:25] <nessy> all good thoughts!
  848. # [06:28] <nessy> I think we're starting to feel the pain between close and loose coupling
  849. # [06:37] * Joins: weinig (~weinig@c-24-130-56-198.hsd1.ca.comcast.net)
  850. # [06:39] * Quits: sephr (~Eli@c-98-235-63-240.hsd1.pa.comcast.net) (Ping timeout: 246 seconds)
  851. # [06:42] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
  852. # [06:44] * Joins: nessy (~Adium@74.125.56.18)
  853. # [06:45] * Quits: cpearce (~chatzilla@203-97-204-82.dsl.clear.net.nz) (Ping timeout: 250 seconds)
  854. # [06:46] * Quits: nessy (~Adium@74.125.56.18) (Client Quit)
  855. # [06:47] * Joins: dbaron (~dbaron@173-228-28-143.dsl.dynamic.sonic.net)
  856. # [06:58] * Joins: KaOSoFt (~KaOSoFt@186.112.5.183)
  857. # [06:58] * Quits: KaOSoFt (~KaOSoFt@186.112.5.183) (Changing host)
  858. # [06:58] * Joins: KaOSoFt (~KaOSoFt@unaffiliated/kaosoft)
  859. # [07:15] <Hixie> actually i guess i have to support the offset thing, because otherwise setting currentTime on the video would be even weirder
  860. # [07:15] <Hixie> i wonder what nessy did in her proposal
  861. # [07:16] <Hixie> "currentTime of the slaves is turned into a readonly attribute"
  862. # [07:16] <Hixie> o_O
  863. # [07:16] * Joins: nessy (~Adium@1.40.227.163)
  864. # [07:16] <Hixie> nessy: what does "currentTime of the slaves is turned into a readonly attribute" mean in your proposal?
  865. # [07:17] * Joins: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net)
  866. # [07:17] <nessy> it means that they slaves are slaved to the timeline of the master and cannot seek on their own
  867. # [07:18] <Hixie> so what happens when you set a slave's .currentTime attribute?
  868. # [07:18] <nessy> however, they may not be fully in sync with the master, so the currenTime does display where they are actually at
  869. # [07:18] * Joins: maikmerten (~merten@ls5dhcp197.cs.uni-dortmund.de)
  870. # [07:18] <nessy> nothing - it's rejected
  871. # [07:18] <nessy> but that was something I randomly made up - not sure it makes sense
  872. # [07:18] <Hixie> the setter just ignores the new value?
  873. # [07:18] <nessy> it was part of slaving everything to the master
  874. # [07:18] <nessy> yes
  875. # [07:18] <Hixie> huh
  876. # [07:19] <nessy> I guess it would be possible - if the master is paused - to set the slave and play with it individually
  877. # [07:20] <nessy> but as soon as the master (or controller) is touched, then the slaves would re-sync with it
  878. # [07:21] <Hixie> it seems really weird to have a mutable attribute whose value changes but which ignores values it is set to
  879. # [07:22] <Hixie> i wonder how else to handle this
  880. # [07:22] <Hixie> i guess i'll have to support the offsets after all
  881. # [07:22] <Hixie> hmm
  882. # [07:24] * Quits: aho (~nya@fuld-590c623e.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
  883. # [07:31] * Joins: nessy1 (~Adium@49.182.30.74)
  884. # [07:32] <nessy1> curious: what does it have to do with offsets?
  885. # [07:32] <Hixie> ignoring a new value in a mutable attribute is bad api design, so imho not an option
  886. # [07:32] <nessy1> ok, fair enough - but how else to deal with it?
  887. # [07:32] <Hixie> exactly
  888. # [07:33] <Hixie> if we have to make it do something, what is the logical thing for it to do?
  889. # [07:33] <Hixie> i see two options:
  890. # [07:33] <nessy1> you could play independently, I guess
  891. # [07:33] <Hixie> making all the currentTimes into proxies for each other, and making it just change that element's position
  892. # [07:33] * nessy1 is on a ferry, so may drop out randomly, sorry
  893. # [07:33] * Joins: Ankheg (~Ankheg@fs91-201-3-30.dubna-net.ru)
  894. # [07:33] <Hixie> now if we grant that the elements must remain synced, then the second is equivalent to setting an offset
  895. # [07:34] * Quits: nessy (~Adium@1.40.227.163) (Read error: Operation timed out)
  896. # [07:34] <Hixie> the former seems bad because there's no intuitive reason why setting one track's position should affect other tracks, especially since it might set the other tracks to entirely different numbers
  897. # [07:34] <Hixie> (since they might have different "zero" times)
  898. # [07:34] <nessy1> except if you interpret the second as a local positioning only - so when the user changes the currentTime of the controller, it snaps back into place
  899. # [07:35] <Hixie> that would be essentially useless, especially while playing
  900. # [07:35] <Hixie> designing useless APIs is also bad api design :-)
  901. # [07:35] <nessy1> how so?
  902. # [07:35] * Quits: dbaron (~dbaron@173-228-28-143.dsl.dynamic.sonic.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  903. # [07:35] <Hixie> it's essentially the same as saying it's ignored
  904. # [07:36] <nessy1> I can see it very useful - e.g. I have a sign language track and a main video - I watch both - I miss some parts in the sign language and just scroll back on that to watch something again - then I play the full composition again in sync
  905. # [07:36] <Hixie> if you can play one track and the others don't move then it's not synced...
  906. # [07:36] <nessy1> not when you directly interact with it
  907. # [07:37] <nessy1> isn't that the beauty of a controller?
  908. # [07:37] <Hixie> the beauty of a controller is that the api isn't asymetric
  909. # [07:37] <nessy1> that it only controls when interacted with it and otherwise leaves the slaves alone?
  910. # [07:38] * Quits: jwalden (~waldo@63.224.145.184) (Quit: back tomorrow)
  911. # [07:38] <Hixie> you can't interact with a controller, it's a js object, it has no UI
  912. # [07:38] <Hixie> i'm not sure i follow what you're proposing
  913. # [07:38] <Hixie> anyway i have to go to bed now
  914. # [07:38] <nessy1> well, if they are all slaved together, then I don't see why the first option doesn't make sense
  915. # [07:38] <Hixie> i'll finish this tomorrow night i guess
  916. # [07:38] <nessy1> no worries
  917. # [07:38] <nessy1> nn
  918. # [07:38] <nessy1> (it's hard!)
  919. # [07:39] <Hixie> this is by orders of magnitude not what i'd call hard, it's just finicky
  920. # [07:39] <Hixie> if you think this is hard you should try writing the html parser spec :-)
  921. # [07:40] <Hixie> nn
  922. # [07:40] * Quits: davve__ (~davve@83.218.67.122) (Remote host closed the connection)
  923. # [07:41] * Joins: davve__ (~davve@83.218.67.122)
  924. # [07:44] * Quits: KaOSoFt (~KaOSoFt@unaffiliated/kaosoft) (Quit: Liberty is the right to choose, freedom is the result of that choice.)
  925. # [07:45] * Quits: nessy1 (~Adium@49.182.30.74) (Quit: Leaving.)
  926. # [07:46] * Joins: Xano (~bart@524B818E.cm-4-4c.dynamic.ziggo.nl)
  927. # [08:06] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  928. # [08:11] * Quits: CvP (~CvP@123.49.20.44) (Disconnected by services)
  929. # [08:11] * Joins: xCG (~CvP@123.49.20.44)
  930. # [08:12] * xCG is now known as CvP
  931. # [08:15] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  932. # [08:24] * Joins: rimantas (~rimliu@93.93.57.193)
  933. # [08:28] * Joins: zcorpan (~zcorpan@c-519de355.410-6-64736c14.cust.bredbandsbolaget.se)
  934. # [08:29] * Quits: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net) (Quit: xbuzz_)
  935. # [08:34] * Quits: weinig (~weinig@c-24-130-56-198.hsd1.ca.comcast.net) (Quit: weinig)
  936. # [08:36] * Joins: MrOpposite (~mropposit@unaffiliated/mropposite)
  937. # [08:36] * Joins: KaOSoFt (~KaOSoFt@186.112.5.183)
  938. # [08:36] * Quits: KaOSoFt (~KaOSoFt@186.112.5.183) (Changing host)
  939. # [08:36] * Joins: KaOSoFt (~KaOSoFt@unaffiliated/kaosoft)
  940. # [08:37] * Quits: KaOSoFt (~KaOSoFt@unaffiliated/kaosoft) (Client Quit)
  941. # [08:38] * Joins: pesla (~pesla@188.202.125.121)
  942. # [08:38] * Quits: Xano (~bart@524B818E.cm-4-4c.dynamic.ziggo.nl) (Quit: Beer o'clock!)
  943. # [08:40] * Joins: Maurice (~ano@77.222.73.150)
  944. # [08:42] * Quits: pesla (~pesla@188.202.125.121) (Ping timeout: 240 seconds)
  945. # [08:54] * Quits: Ankheg (~Ankheg@fs91-201-3-30.dubna-net.ru) (Ping timeout: 240 seconds)
  946. # [08:54] * Joins: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net)
  947. # [08:56] <zcorpan> Hixie: i'm happy to review books
  948. # [08:56] * Joins: Ankheg (~Ankheg@91.201.3.30)
  949. # [08:57] <zcorpan> at least if "review" means "point out errors to the author", not "publish a review to make the book sell more copies"
  950. # [08:58] * Joins: kor (~kor@ip146-53-210-87.adsl2.static.versatel.nl)
  951. # [08:59] * Quits: jennb (~jennb@74.125.59.73) (Quit: jennb)
  952. # [09:01] * Quits: Smylers (~smylers@host109-157-249-110.range109-157.btcentralplus.com) (Ping timeout: 240 seconds)
  953. # [09:04] * Joins: VISHAL (~VISHAL@122.179.131.53)
  954. # [09:04] * Quits: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net) (Quit: cying)
  955. # [09:05] <VISHAL> Hi
  956. # [09:05] <VISHAL> Hope this is the right channel to ask about html5
  957. # [09:10] <VISHAL> i am trying to access the server to get some data using ajax aplication is on same server but it shows Origin null is not allowed by Access-Control-Allow-Origin
  958. # [09:10] * Quits: drunknbass (~drunknbas@76.91.255.83) (Read error: Connection reset by peer)
  959. # [09:11] * Joins: drunknbass (~drunknbas@76.91.255.83)
  960. # [09:12] * Quits: VISHAL (~VISHAL@122.179.131.53) (Quit: Leaving)
  961. # [09:13] * Joins: VISHAL (~VISHAL@122.179.131.53)
  962. # [09:14] * Quits: MrOpposite (~mropposit@unaffiliated/mropposite) (Remote host closed the connection)
  963. # [09:22] * Quits: drunknbass (~drunknbas@76.91.255.83) (Ping timeout: 264 seconds)
  964. # [09:22] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  965. # [09:23] <zcorpan> Hixie: there's a problem with overlaying a sign-language video and using native controls
  966. # [09:23] <zcorpan> Hixie: because the overlaid video overlaps the native controls
  967. # [09:24] * Joins: drunknbass (~drunknbas@76.91.255.83)
  968. # [09:24] * Joins: nessy (~Adium@124-168-15-54.dyn.iinet.net.au)
  969. # [09:27] * zcorpan filed a bug
  970. # [09:28] * Quits: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net) (Quit: xbuzz_)
  971. # [09:30] * Quits: drunknbass (~drunknbas@76.91.255.83) (Ping timeout: 240 seconds)
  972. # [09:32] * Joins: msucan (~robod@89.123.146.211)
  973. # [09:33] * eighty4_ is now known as eighty4
  974. # [09:33] * Quits: eighty4 (~eighty4@li150-164.members.linode.com) (Changing host)
  975. # [09:33] * Joins: eighty4 (~eighty4@unaffiliated/eighty4)
  976. # [09:33] * Joins: drunknbass (~drunknbas@76.91.255.83)
  977. # [09:34] <hsivonen> what's the most realistic documentation of mutation events?
  978. # [09:35] * Quits: drunknbass (~drunknbas@76.91.255.83) (Read error: Connection reset by peer)
  979. # [09:35] * Joins: haumold (~drunknbas@76.91.255.83)
  980. # [09:36] * Joins: kal-EL_ (~jor-EL@host68-38-dynamic.248-95-r.retail.telecomitalia.it)
  981. # [09:37] * Joins: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net)
  982. # [09:39] * Joins: cpearce (~chatzilla@ip-118-90-94-177.xdsl.xnet.co.nz)
  983. # [09:42] * Quits: haumold (~drunknbas@76.91.255.83) (Ping timeout: 276 seconds)
  984. # [09:45] * Joins: drunknbass (~drunknbas@76.91.255.83)
  985. # [09:48] * Joins: jochen___ (~jochen@nat/google/x-rsbtlfmlfnojxonm)
  986. # [09:48] * Quits: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net) (Quit: cying)
  987. # [09:51] * Quits: drunknbass (~drunknbas@76.91.255.83) (Ping timeout: 250 seconds)
  988. # [09:52] * Quits: jochen__ (~jochen@nat/google/x-oxbpdigyunshjtkv) (Ping timeout: 248 seconds)
  989. # [09:52] * jochen___ is now known as jochen__
  990. # [09:53] * Joins: matijsb (~matijsb@188.205.108.18)
  991. # [09:54] * Joins: drunknbass (~drunknbas@76.91.255.83)
  992. # [09:55] * Quits: kig (~kig@dsl-lprbrasgw1-fee6f900-146.dhcp.inet.fi) (Quit: leaving)
  993. # [09:55] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  994. # [09:56] * Joins: mhausenblas_ (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  995. # [09:59] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Ping timeout: 250 seconds)
  996. # [09:59] * mhausenblas_ is now known as mhausenblas
  997. # [10:04] * Joins: jochen___ (~jochen@nat/google/x-nczhvwyomagkgrdp)
  998. # [10:04] * Quits: ojan (~ojan@74.125.56.17) (Quit: ojan)
  999. # [10:04] * Quits: drunknbass (~drunknbas@76.91.255.83) (Ping timeout: 252 seconds)
  1000. # [10:08] * Quits: jochen__ (~jochen@nat/google/x-rsbtlfmlfnojxonm) (Ping timeout: 264 seconds)
  1001. # [10:08] * jochen___ is now known as jochen__
  1002. # [10:10] * Joins: kennyluck (~kennyluck@EM111-188-69-72.pool.e-mobile.ne.jp)
  1003. # [10:10] * Quits: kennyluck (~kennyluck@EM111-188-69-72.pool.e-mobile.ne.jp) (Excess Flood)
  1004. # [10:14] * Quits: cpearce (~chatzilla@ip-118-90-94-177.xdsl.xnet.co.nz) (Read error: Connection reset by peer)
  1005. # [10:15] * Joins: cpearce (~chatzilla@ip-118-90-94-177.xdsl.xnet.co.nz)
  1006. # [10:15] * Joins: kennyluck (~kennyluck@EM111-188-69-72.pool.e-mobile.ne.jp)
  1007. # [10:25] * Quits: zcorpan (~zcorpan@c-519de355.410-6-64736c14.cust.bredbandsbolaget.se) (Ping timeout: 240 seconds)
  1008. # [10:32] * Joins: mhausenblas_ (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  1009. # [10:36] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Ping timeout: 246 seconds)
  1010. # [10:36] * mhausenblas_ is now known as mhausenblas
  1011. # [10:36] * Joins: zcorpan (~zcorpan@c-519de355.410-6-64736c14.cust.bredbandsbolaget.se)
  1012. # [10:36] * Joins: mpt (~mpt@91.189.88.12)
  1013. # [10:36] * Quits: mpt (~mpt@91.189.88.12) (Changing host)
  1014. # [10:36] * Joins: mpt (~mpt@canonical/mpt)
  1015. # [10:43] * Joins: mhausenblas_ (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  1016. # [10:45] * Quits: plomlompom (~plomlompo@i59F6BC30.versanet.de) (Ping timeout: 248 seconds)
  1017. # [10:46] * Joins: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net)
  1018. # [10:46] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Ping timeout: 248 seconds)
  1019. # [10:46] * mhausenblas_ is now known as mhausenblas
  1020. # [10:47] * Quits: othermaciej (~mjs@c-24-6-209-6.hsd1.ca.comcast.net) (Quit: othermaciej)
  1021. # [10:53] * Joins: plomlompom (~plomlompo@88.130.175.56)
  1022. # [10:53] * Quits: roc (~chatzilla@203-97-204-82.dsl.clear.net.nz) (Ping timeout: 260 seconds)
  1023. # [10:54] <gsnedders> Where does WebIDL forbid assignment to read only attributes in the ES binding?
  1024. # [10:55] * Joins: dirkpennings (~Vuurbal@90-145-26-140.bbserv.nl)
  1025. # [10:58] <gsnedders> Oh, "The attribute setter is undefined if the attribute is declared readonly and has neither a [PutForwards] nor a [Replaceable] extended attribute declared on it"
  1026. # [10:59] <gsnedders> Which means that the exact behaviour depends upon strict-mode
  1027. # [11:02] <foolip> Hixie, I'm here now
  1028. # [11:02] * Joins: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se)
  1029. # [11:05] * Joins: tbassetto (~tbassetto@92.103.127.226)
  1030. # [11:06] * Quits: foolip (~philip@83.218.67.122) (Quit: Ex-Chat)
  1031. # [11:06] * Joins: erlehmann (~erlehmann@89.204.137.76)
  1032. # [11:07] * Quits: davve__ (~davve@83.218.67.122) (Remote host closed the connection)
  1033. # [11:07] * Joins: roc (~chatzilla@121.98.230.221)
  1034. # [11:11] * Joins: roc__ (~chatzilla@121.98.230.221)
  1035. # [11:12] * Quits: roc (~chatzilla@121.98.230.221) (Ping timeout: 240 seconds)
  1036. # [11:12] * roc__ is now known as roc
  1037. # [11:14] <Lachy> Hixie, yt?
  1038. # [11:18] <jgraham> gsnedders: Yes]
  1039. # [11:18] <jgraham> Lachy: 00:34 < Hixie> anyway i have to go to bed now
  1040. # [11:19] * Joins: MikeSmith (~MikeSmith@EM111-188-9-197.pool.e-mobile.ne.jp)
  1041. # [11:19] <jgraham> I know that isn't always a reliable indicator, but it was 4 hours ago
  1042. # [11:20] <Lachy> jgraham, "00:34" is 11 hours ago, unless you're running in a weird timezone
  1043. # [11:21] * Quits: Workshiva (~Dashiva@74.125.57.33) (Quit: leaving)
  1044. # [11:21] <jgraham> Yes the server is in the US somewhere and I am too lazy to change the timezone in irssi
  1045. # [11:21] <Lachy> ok
  1046. # [11:22] * Joins: Workshiva (~Dashiva@74.125.121.65)
  1047. # [11:22] * Joins: Workmon (~Dashiva@74.125.121.65)
  1048. # [11:23] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: Leaving)
  1049. # [11:23] * Quits: Workmon (~Dashiva@74.125.121.65) (Client Quit)
  1050. # [11:23] <zcorpan> ok i have updated http://dev.w3.org/html5/html4-differences/
  1051. # [11:24] <zcorpan> i guess i should set the date to 5th also
  1052. # [11:25] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  1053. # [11:25] <zcorpan> there
  1054. # [11:26] * Joins: Necrathex (~nectop@82-170-160-25.ip.telfort.nl)
  1055. # [11:32] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  1056. # [11:41] <jgraham> Hixie: BTW I might also be interested in doing book review, if they need more volunteers (assuming the same definition as zcorpan)
  1057. # [11:44] <jgraham> MikeSmith: BTW, as gsnedders reminded me, I will not be around on 20th May, and possibly some of the following week
  1058. # [12:00] <hsivonen> anyone got an insertAdjacentHTML test suite_
  1059. # [12:00] <hsivonen> ?
  1060. # [12:03] <jgraham> I don't at least
  1061. # [12:17] <hsivonen> googling for mutation events shows an unfortunate interest in them
  1062. # [12:36] * Joins: Xano (~bart@524B818E.cm-4-4c.dynamic.ziggo.nl)
  1063. # [12:36] <hsivonen> Someone seem to believe that whatwg members want to filter Norm: http://twitter.com/#!/gimsieke/status/51567252096548865
  1064. # [12:36] * Joins: davve__ (~davve@83.218.67.122)
  1065. # [12:40] * Joins: agektmr (~Adium@64.211.20.2)
  1066. # [12:53] * Joins: davidhund (~davidhund@78-27-27-74.dsl.alice.nl)
  1067. # [13:07] * Joins: smaug____ (~chatzilla@YZMYCMXXIV.gprs.sl-laajakaista.fi)
  1068. # [13:22] * Joins: foolip (~philip@83.218.67.122)
  1069. # [13:30] * Joins: FireFly (~firefly@unaffiliated/firefly)
  1070. # [13:46] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
  1071. # [13:52] * Joins: jeremyselier (~Jeremy@92.103.127.226)
  1072. # [13:52] * Quits: smaug____ (~chatzilla@YZMYCMXXIV.gprs.sl-laajakaista.fi) (Ping timeout: 240 seconds)
  1073. # [13:58] <MikeSmith> jgraham: how about the week of May 8 to 14?
  1074. # [13:58] <jgraham> MikeSmith: That is good for me, but before gsnedders finishes his exams
  1075. # [13:58] <MikeSmith> oh
  1076. # [13:59] <MikeSmith> anyway, I'm busy on the 20th as well
  1077. # [13:59] <MikeSmith> but free after that
  1078. # [13:59] <jgraham> I will *probably* be free the following week
  1079. # [14:00] <jgraham> Not sure about gsnedders though
  1080. # [14:00] * Quits: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net) (Quit: xbuzz_)
  1081. # [14:00] <MikeSmith> OK, let's see what he says when he's back here
  1082. # [14:01] <MikeSmith> zcorpan: doc looks good
  1083. # [14:01] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
  1084. # [14:01] * Joins: hdhoang (~hdhoang@203.210.153.16)
  1085. # [14:01] <MikeSmith> I will try to get it staged up today at http://www.w3.org/TR/2011/WD-html5-diff-20110405/
  1086. # [14:03] <MikeSmith> hmm "The action and formaction attributes are no longer allowed to have the empty string as value."
  1087. # [14:04] * MikeSmith tries to remember if any validator fix has been made for that yet
  1088. # [14:04] <MikeSmith> oh yeah, value is common.data.uri.non-empty
  1089. # [14:06] <zcorpan> MikeSmith: cool
  1090. # [14:13] * Quits: hdhoang (~hdhoang@203.210.153.16) (Ping timeout: 276 seconds)
  1091. # [14:14] <hsivonen> wow. this time writing test cases really pays off
  1092. # [14:14] * hsivonen is implementing insertAdjacentHTML
  1093. # [14:15] <jgraham> hsivonen: Planning to release the tests?
  1094. # [14:16] <hsivonen> jgraham: yes, in the "pushed to m-c" sense
  1095. # [14:16] <hsivonen> jgraham: other publication depends on how easy it is to repurpose mochitests as HTML WG tests
  1096. # [14:23] * Quits: Rik` (~Rik`@2a01:e34:ec0f:1570:daa2:5eff:fe97:85ed) (Remote host closed the connection)
  1097. # [14:24] * Quits: nessy (~Adium@124-168-15-54.dyn.iinet.net.au) (Quit: Leaving.)
  1098. # [14:25] <hsivonen> jgraham: the tests are now public but not necessarily useful outside mochitest: https://bugzilla.mozilla.org/attachment.cgi?id=523283&action=diff
  1099. # [14:36] <volkmar> someone knows what could be the labels attribute use case? (I see a few internal browser stuff but not for authors)
  1100. # [14:37] <hsivonen> jgraham: Is the execution flow in HTML WG test harness one-to-one mappable to mochitest yet?
  1101. # [14:41] * Joins: hdhoang (~hdhoang@203.210.156.121)
  1102. # [14:49] <jgraham> hsivonen: I think the answer to your question is probably "no" although I don't understand the question.
  1103. # [14:50] <jgraham> One could write a MochiTest wrapper for the HTML WG harness
  1104. # [14:50] <hsivonen> jgraham: could I just take the tests that I linked to above, change the assertion function names and have it work?
  1105. # [14:50] <jgraham> No
  1106. # [14:50] <hsivonen> (maybe adding some kind of explicit finish() call)
  1107. # [14:50] <hsivonen> jgraham: ok :-(
  1108. # [14:51] <zcorpan> jgraham: btw, it'd be nice with a second version of t.step() that returns a function
  1109. # [14:52] <hsivonen> jgraham: I'd really like to get to a point where the difference between Mochtest and HTML WG tests is just trivialities in naming that can be addressed with a simple wrapper
  1110. # [14:52] <hsivonen> but I really don't expect to spend the time to adapt mochitests to .step() in order to contribute
  1111. # [14:57] * Joins: Rik` (~Rik`@mozilla-paris-253-99.cnt.nerim.net)
  1112. # [15:00] * Joins: boaz (~boaz@75-150-66-249-NewEngland.hfc.comcastbusiness.net)
  1113. # [15:04] <jgraham> zcorpan: Yes, I was thinking t.step_func or so
  1114. # [15:05] <jgraham> hsivonen: It would be trivial to write a wrapper that collected the results of a HTMLWG test and returned them to mochitest
  1115. # [15:05] <jgraham> s/HTMLWG/testharness.js/
  1116. # [15:05] <jgraham> zcorpan: I can add that now if you need it
  1117. # [15:06] <hsivonen> jgraham: what about the other way round?
  1118. # [15:06] <jgraham> hsivonen: I don't know about the other way around because I don't know how MochiTest exposes its test results
  1119. # [15:07] <jgraham> testharness.js has callbacks for each test that completes and for the whole suite completing
  1120. # [15:08] <jgraham> So you would just hook into those and do something like function on_result(test) {is(test.result === test.PASS, test.message)}
  1121. # [15:08] <jgraham> (and hook on_result up to the right callbacks)
  1122. # [15:10] <zcorpan> jgraham: that'd be nice
  1123. # [15:11] <hsivonen> jgraham: what about window.onerror?
  1124. # [15:16] <jgraham> hsivonen: What about it?
  1125. # [15:17] <hsivonen> jgraham: are tests that rely on window.onerror now accepted in HTML WG test submissions?
  1126. # [15:17] <jgraham> Rely on it in what way? Tests that test it are fine
  1127. # [15:18] <jgraham> Tests that require it when they don't need to seem extremely dubious to me
  1128. # [15:18] * Joins: Bass10 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  1129. # [15:18] <hsivonen> jgraham: If something in the global scope fails, it is caught by window.onerror
  1130. # [15:19] <hsivonen> which would matter if we submitted tests that failed in some UA
  1131. # [15:19] <jgraham> hsivonen: In general relying on that is discouraged, not least becase when testing window.onerror one will need exceptions that propogate to the global scope
  1132. # [15:22] <zcorpan> jgraham: step_func would support only one argument, right? javascript doesn't support passing along an arbitrary number of arguments, does it
  1133. # [15:23] <jgraham> zcorpan: Sure it does
  1134. # [15:24] <zcorpan> oh?
  1135. # [15:24] <hsivonen> I think Mozilla needs someone whose primary work item is wrapping HTML WG tests into the mochitest reporting system and wrapping mochitests into the HTML WG reporting system
  1136. # [15:24] <jgraham> hsivonen: http://hoppipolla.co.uk/tests/insert_adjacent_html.html is a very quick transliteration, which probably has bugs
  1137. # [15:27] <gsnedders> MikeSmith: 8 to 14th definitely can't do. Week after the 20th I *might* be able to do. Almost certainly end of that is doable.
  1138. # [15:27] <MikeSmith> ok
  1139. # [15:29] <Workshiva> zcorpan: apply is your friend
  1140. # [15:29] <jgraham> Workshiva: Or your enemy
  1141. # [15:30] <Workshiva> Only if you mistreat it
  1142. # [15:33] * Joins: bfrohs (~bfrohs@smtp.forewordinternal.com)
  1143. # [15:33] * Joins: plainhao (~plainhao@208.75.85.237)
  1144. # [15:34] <zcorpan> ah
  1145. # [15:34] * zcorpan doesn't know the javascript fu
  1146. # [15:34] <hsivonen> jgraham: there are somefailures in the translation in my build that passes the mochitest
  1147. # [15:35] <hsivonen> jgraham: all "Should have had <a> as next sibling" tests throw
  1148. # [15:35] * Joins: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net)
  1149. # [15:36] <hsivonen> and tests 30 though 33 say expected is undefined
  1150. # [15:36] <jgraham> so you ant to be able to do something like something.some_event = t.step_func(function(e) {assert_equals(1, e.a)}) or something?
  1151. # [15:37] <zcorpan> yes
  1152. # [15:38] <zcorpan> so one argument is good enough for me
  1153. # [15:39] * Quits: Ankheg (~Ankheg@91.201.3.30) (Read error: Connection reset by peer)
  1154. # [15:42] * Joins: smaug____ (~chatzilla@cs181139127.pp.htv.fi)
  1155. # [15:42] <Workshiva> Just make sure you get an argument and not abuse
  1156. # [15:43] * Quits: agektmr (~Adium@64.211.20.2) (Quit: Leaving.)
  1157. # [15:44] <jgraham> hsivonen: typo, fixed
  1158. # [15:44] * Joins: miketaylr (~miketaylr@206.217.92.186)
  1159. # [15:45] * Joins: eric_carlson (~eric_carl@2620:0:1b00:1191:217:f2ff:fe03:a2e)
  1160. # [15:46] <jgraham> Oh, I missed the "script should not have run" bits
  1161. # [15:48] <hsivonen> jgraham: now all tests pass
  1162. # [15:49] * Joins: svl (~me@186.130.48.69)
  1163. # [15:50] * Quits: kal-EL_ (~jor-EL@host68-38-dynamic.248-95-r.retail.telecomitalia.it) (Remote host closed the connection)
  1164. # [15:50] * Quits: kennyluck (~kennyluck@EM111-188-69-72.pool.e-mobile.ne.jp) (Quit: kennyluck)
  1165. # [15:51] <jgraham> hsivonen: Fancy cleaning up the "script should not have run" bits (e.g. by setting a flag in the script and checking its value doesn't change) and submitting to HTML WG?
  1166. # [15:52] <jgraham> Or I could do that I suppose…
  1167. # [15:52] * Quits: erlehmann (~erlehmann@89.204.137.76) (Quit: Ex-Chat)
  1168. # [15:57] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
  1169. # [15:57] * Joins: david_carlisle (~davidc@86.188.197.189)
  1170. # [15:59] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Quit: Ex-Chat)
  1171. # [16:01] * Joins: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de)
  1172. # [16:02] <gsnedders> MikeSmith: I guess a more reasonable question from my POV is when is the latest the meeting can be to suit you?
  1173. # [16:03] <MikeSmith> the end of that week I guess
  1174. # [16:06] * Quits: maikmerten (~merten@ls5dhcp197.cs.uni-dortmund.de) (Remote host closed the connection)
  1175. # [16:09] * Joins: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com)
  1176. # [16:10] <hsivonen> jgraham: I can do it, but if you are already doing it, go ahead
  1177. # [16:11] * Joins: cooto (~Adium@190.98.195.170)
  1178. # [16:12] <gsnedders> MikeSmith: mmhmm, maybe doable
  1179. # [16:12] * Parts: cooto (~Adium@190.98.195.170)
  1180. # [16:14] <jgraham> gsnedders: Am I missing something on the RegExp.prototype.compile thread?
  1181. # [16:15] * Joins: phrearch (~phrearch_@82-136-229-19.ip.telfort.nl)
  1182. # [16:15] * Quits: MikeSmith (~MikeSmith@EM111-188-9-197.pool.e-mobile.ne.jp) (Ping timeout: 246 seconds)
  1183. # [16:15] <gsnedders> jgraham: I'm sure I am.
  1184. # [16:16] <jgraham> gsnedders: OK, your reply makes sense to me
  1185. # [16:21] <gsnedders> jgraham: At least it makes sense to someone
  1186. # [16:29] * Joins: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net)
  1187. # [16:30] * Joins: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  1188. # [16:30] * Parts: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  1189. # [16:34] * Quits: kor (~kor@ip146-53-210-87.adsl2.static.versatel.nl) (Quit: kor)
  1190. # [16:48] * Joins: badmin (~quassel@ip-109-91-39-31.unitymediagroup.de)
  1191. # [16:48] * Joins: kor (~kor@ip146-53-210-87.adsl2.static.versatel.nl)
  1192. # [16:48] * badmin is now known as Guest21089
  1193. # [16:48] * Guest21089 is now known as admiralf
  1194. # [16:49] * Parts: bfrohs (~bfrohs@smtp.forewordinternal.com)
  1195. # [16:50] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Quit: Now time for the weather. Tiffany?)
  1196. # [16:51] * Joins: bfrohs (~bfrohs@smtp.forewordinternal.com)
  1197. # [16:52] * Quits: jeremyselier (~Jeremy@92.103.127.226) (Read error: Operation timed out)
  1198. # [16:53] * Joins: kennyluck (~kennyluck@EM114-48-207-191.pool.e-mobile.ne.jp)
  1199. # [16:53] * Quits: kennyluck (~kennyluck@EM114-48-207-191.pool.e-mobile.ne.jp) (Excess Flood)
  1200. # [16:54] * Joins: kennyluck (~kennyluck@EM114-48-207-191.pool.e-mobile.ne.jp)
  1201. # [16:55] * Quits: kennyluck (~kennyluck@EM114-48-207-191.pool.e-mobile.ne.jp) (Client Quit)
  1202. # [16:55] * Joins: kennyluck (~kennyluck@EM114-48-207-191.pool.e-mobile.ne.jp)
  1203. # [16:55] * Quits: kennyluck (~kennyluck@EM114-48-207-191.pool.e-mobile.ne.jp) (Excess Flood)
  1204. # [16:56] * Joins: kennyluck (~kennyluck@EM114-48-207-191.pool.e-mobile.ne.jp)
  1205. # [16:59] * Joins: jeremyselier (~Jeremy@2a01:e35:2eec:80a0:fa1e:dfff:feec:469)
  1206. # [17:02] * zcorpan notes that there's no EventSourceSync for workers
  1207. # [17:02] * Joins: Kingdutch (~Kingdutch@188.200.149.217)
  1208. # [17:02] <zcorpan> but maybe that doesn't make any sense
  1209. # [17:03] * Quits: Kingdutch (~Kingdutch@188.200.149.217) (Read error: Connection reset by peer)
  1210. # [17:03] * Joins: Kingdutch (~Kingdutch@188.200.149.217)
  1211. # [17:04] * Joins: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de)
  1212. # [17:04] * Quits: zcorpan (~zcorpan@c-519de355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
  1213. # [17:06] * Joins: MikeSmith (~MikeSmith@EM114-48-22-161.pool.e-mobile.ne.jp)
  1214. # [17:06] * Quits: riven (~riven@pdpc/supporter/professional/riven) (Read error: Connection reset by peer)
  1215. # [17:06] * Quits: Maurice (~ano@77.222.73.150) (Quit: Disconnected...)
  1216. # [17:07] * Joins: riven (~riven@pdpc/supporter/professional/riven)
  1217. # [17:17] * Joins: maikmerten (~maikmerte@port-92-201-154-167.dynamic.qsc.de)
  1218. # [17:17] * Quits: phrearch (~phrearch_@82-136-229-19.ip.telfort.nl) (Read error: Operation timed out)
  1219. # [17:20] * Joins: zdobersek (~zan@cpe-46-164-29-246.dynamic.amis.net)
  1220. # [17:28] * Joins: Bass2 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  1221. # [17:30] * Quits: Bass10 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Ping timeout: 246 seconds)
  1222. # [17:33] * Joins: phrearch (~phrearch_@82-136-229-19.ip.telfort.nl)
  1223. # [17:37] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Ping timeout: 246 seconds)
  1224. # [17:37] * Joins: BLOB0 (blobo@and.what.makes.you.verymad.net)
  1225. # [17:38] * Quits: hdhoang (~hdhoang@203.210.156.121) (Quit: Leaving.)
  1226. # [17:39] * Quits: svl (~me@186.130.48.69) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1227. # [17:48] * Quits: david_carlisle (~davidc@86.188.197.189) (Ping timeout: 264 seconds)
  1228. # [17:49] * Joins: othermaciej (~mjs@c-24-6-209-6.hsd1.ca.comcast.net)
  1229. # [17:51] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 252 seconds)
  1230. # [17:56] * Quits: zdobersek (~zan@cpe-46-164-29-246.dynamic.amis.net) (Quit: Leaving.)
  1231. # [17:58] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  1232. # [17:59] <zewt> ... websql stopped because sqlite was too good? heh
  1233. # [18:02] * Quits: admiralf (~quassel@ip-109-91-39-31.unitymediagroup.de) (Remote host closed the connection)
  1234. # [18:02] * Joins: KaOSoFt (~KaOSoFt@186.112.5.183)
  1235. # [18:02] * Quits: KaOSoFt (~KaOSoFt@186.112.5.183) (Changing host)
  1236. # [18:02] * Joins: KaOSoFt (~KaOSoFt@unaffiliated/kaosoft)
  1237. # [18:03] * Joins: aho (~nya@fuld-590c65e7.pool.mediaWays.net)
  1238. # [18:07] * Quits: eighty4 (~eighty4@unaffiliated/eighty4) (Ping timeout: 250 seconds)
  1239. # [18:09] * Joins: agektmr (~Adium@nat/google/x-ckbbssanjlgqqyau)
  1240. # [18:09] * Joins: mpt (~mpt@canonical/mpt)
  1241. # [18:10] <TabAtkins> zewt: More precisely, sqlite was "good enough" that nobody seriously wanted to write an independent implementation. It's still not very good, though.
  1242. # [18:10] * Joins: eighty4 (~eighty4@unaffiliated/eighty4)
  1243. # [18:11] <TabAtkins> (We're currently using sqlite as the backing store for indexeddb, and it's pretty slow and horrible. We're writing a specialized backing store just for it right now.)
  1244. # [18:11] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  1245. # [18:11] <zewt> sqlite is pretty excellent; it's definitely not "slow and horrible"
  1246. # [18:11] <TabAtkins> Tell that to our indexeddb folks.
  1247. # [18:12] * Quits: davidhund (~davidhund@78-27-27-74.dsl.alice.nl) (Quit: davidhund)
  1248. # [18:12] <zewt> idb seems like a heinous wheel reinvention; the world doesn't need another completely distinct database vocabulary
  1249. # [18:12] <zewt> (vs. sql)
  1250. # [18:13] <TabAtkins> indexeddb is a pretty standard simple object store.
  1251. # [18:13] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 248 seconds)
  1252. # [18:14] <zewt> and they're spending all kinds of time trying to solve things like "how do we define multi-key indexes with different orderings on each key", stuff which is already solved in SQL
  1253. # [18:15] <TabAtkins> Yes?
  1254. # [18:15] <zewt> yes?
  1255. # [18:15] <zewt> sorry, that's not a very meaningful response. heh
  1256. # [18:15] <TabAtkins> SQL is still a relational model, which, for whatever reason, a lot of people simply can't wrap their heads around. I don't understand why, because I found relational algebra pretty trivial, but whatever.
  1257. # [18:16] <TabAtkins> Linear object stores appear to be much more intuitive to most people.
  1258. # [18:16] <TabAtkins> And then we need to find a way to map more advanced concepts onto the simpler model, in a clean and understandable way.
  1259. # [18:17] <zewt> i can't say i have much sympathy for people who can't understand SQL. heh
  1260. # [18:17] <zewt> basic stuff.
  1261. # [18:18] <TabAtkins> I have sympathy for developers in general. That's why I obsess so much over things being simple in my specs.
  1262. # [18:19] <Philip`> Given how many inexperienced people manage to develop web sites with PHP+MySQL, it seems it's understable enough to get by
  1263. # [18:19] * Quits: SteveGL (~dev@174-21-210-154.tukw.qwest.net) (Read error: Operation timed out)
  1264. # [18:19] <TabAtkins> Have you looked at their databases?
  1265. # [18:19] * TabAtkins shudders.
  1266. # [18:19] <zewt> heh, that may not be the most flattering comparison if you consider how secure those sites probably are on the whole :|
  1267. # [18:19] <Philip`> s/understable/understandable/
  1268. # [18:20] <Philip`> Their databases are probably no worse than their PHP code :-)
  1269. # [18:20] * Quits: miketaylr (~miketaylr@206.217.92.186) (Quit: miketaylr)
  1270. # [18:20] <TabAtkins> Point. ^_^
  1271. # [18:20] * Joins: miketaylr (~miketaylr@206.217.92.186)
  1272. # [18:21] <Philip`> They've probably never heard of relation algebra but that doesn't stop them using the tools to solve their problems
  1273. # [18:21] <TabAtkins> Indeed, and the relational algebra does *not* help them solve the problem. They just bodge on and create something pretty bad. We can offer them something that more closely matches their intuitive model, so when they just throw something together it's not as bad.
  1274. # [18:23] <zewt> what bothers me a lot, though, is the notion that WebSQL development died because everyone used sqlite--that's exactly what they should be doing
  1275. # [18:23] <TabAtkins> No, because then the web depends on sqlite's bugs, rather than the spec.
  1276. # [18:23] <zewt> sqlite is in a small category of libraries that are so widely-used, heavily tested and robust that, for tasks it's designed for, it's generally a really bad idea to not use them (along with eg. zlib, libpng/jpeg, etc)
  1277. # [18:24] <TabAtkins> All of those latter libraries definitely have problems as well, and we'd be better off if we spent the effort to reimplement them.
  1278. # [18:24] <TabAtkins> They're just "good enough" that we don't do so.
  1279. # [18:24] <zewt> none of those libraries need reimplementing.
  1280. # [18:25] <TabAtkins> Luckily, the problems with those libraries are almost completely hidden from the web author. Exposing sqlite via websqldb means its problems *aren't* hidden.
  1281. # [18:26] <TabAtkins> Again, ask our devs. I've heard a lot of chatter about people wanting to reimplement libpng, for example, due to its horribleness.
  1282. # [18:26] <Philip`> Seems pretty typical for programmers to want reimplement everything - you always think you can do better yourself
  1283. # [18:27] <zewt> heh
  1284. # [18:27] <zewt> i'm not immune from NIH, but i'd never go there for that set of libraries
  1285. # [18:28] * Joins: jennb (~jennb@74.125.59.65)
  1286. # [18:29] * Quits: maikmerten (~maikmerte@port-92-201-154-167.dynamic.qsc.de) (Remote host closed the connection)
  1287. # [18:30] * Joins: ako (~nya@fuld-590c6bb4.pool.mediaWays.net)
  1288. # [18:32] * Joins: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  1289. # [18:32] * Quits: jennb (~jennb@74.125.59.65) (Client Quit)
  1290. # [18:32] <Philip`> (Usually you *can* do better, because you've got the experience of the old design and an extra decade of research, and better development tools and practices)
  1291. # [18:32] <Philip`> (which makes it dangerously tempting)
  1292. # [18:33] <zewt> oh, you could do better--but not enough better, IMO, to warrant throwing away the extra decade of testing and real-world use
  1293. # [18:33] * Quits: aho (~nya@fuld-590c65e7.pool.mediaWays.net) (Ping timeout: 240 seconds)
  1294. # [18:34] <zewt> (personally, zlib's buffering API always annoys me when I have to use it, for example, but everyone's used to it)
  1295. # [18:35] <Philip`> (API problems are usually the easiest thing to resolve - just stick a wrapper API around it)
  1296. # [18:35] <zewt> yeah.
  1297. # [18:36] <Philip`> (libpng's use of setjmp is kind of nasty, but not enough to really matter)
  1298. # [18:37] <zewt> oh yeah, i forgot about that. lua does that too
  1299. # [18:37] <TabAtkins> I think that's one of the things that annoys some of our devs a lot.
  1300. # [18:37] <zewt> that's pretty much wrappable too, i think.
  1301. # [18:39] * Parts: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  1302. # [18:40] <Philip`> The more important problems are probably things like libjpeg using a poor decoding algorithm (given e.g. http://cbloomrants.blogspot.com/2011/02/02-13-11-jpeg-decoding.html)
  1303. # [18:43] <Philip`> but then it's nice to fix the problems as non-disruptively as possible, e.g. change the implementation but don't redesign the whole API unless it's really necessary, and definitely don't make a whole new file format (e.g. WebP) that's incompatible with everybody else in the world
  1304. # [18:43] <zewt> i'd sooner hope that improvements like that would make their way into libjpeg, not replace it outright
  1305. # [18:44] <zewt> of course, that depends on how flexible libjpeg's internals are (which I have never needed to look at--which is a major part of why I like libjpeg so much :)
  1306. # [18:45] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Remote host closed the connection)
  1307. # [18:48] * Joins: stefan-_ (~music@trir-4d0d8fc6.pool.mediaWays.net)
  1308. # [18:49] * Quits: Bass2 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Ping timeout: 252 seconds)
  1309. # [18:49] <stefan-_> hi
  1310. # [18:49] <stefan-_> how safe in terms of browser compat is it to use a contentEditable based editor?
  1311. # [18:51] <TabAtkins> It's not.
  1312. # [18:51] <TabAtkins> At least, not if you want to use execCommand().
  1313. # [18:52] <TabAtkins> If you're willing to roll your own editting commands, then it's okay.
  1314. # [18:52] <stefan-_> just for simple formatting (bold, underline, etc)
  1315. # [18:52] * Joins: davidhund (~davidhund@dnuhd.xs4all.nl)
  1316. # [18:53] <stefan-_> http://www.freshcode.co.za/plugins/jquery.contentEditable/demo.html
  1317. # [18:53] <stefan-_> im using this one currently
  1318. # [18:53] <stefan-_> seems to work ok in ie6 and chrome so far
  1319. # [18:53] * Quits: agektmr (~Adium@nat/google/x-ckbbssanjlgqqyau) (Quit: Leaving.)
  1320. # [18:54] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Quit: Now time for the weather. Tiffany?)
  1321. # [18:55] <stefan-_> so what you mean with rolling out my own editing commands?
  1322. # [18:56] * Joins: zdobersek (~zan@cpe-46-164-29-246.dynamic.amis.net)
  1323. # [18:56] <stefan-_> http://www.quirksmode.org/dom/execCommand.html
  1324. # [18:56] <stefan-_> nice
  1325. # [18:56] <stefan-_> that should be satisfactory
  1326. # [18:57] * Joins: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com)
  1327. # [18:58] <micheil> Hixie: do you know if all vendors currently implementing websockets support the Events IDL?
  1328. # [18:58] <micheil> (as in WebSocket inherits from the Events api)
  1329. # [19:00] <jgraham> micheil: what do you actually mean?
  1330. # [19:00] <jgraham> All relevant browsers implement DOM events…
  1331. # [19:00] <micheil> well, each websocket instance has the .addListener methods
  1332. # [19:01] <micheil> is a websocket guaranteed to inherit from DOMEvents
  1333. # [19:02] <jgraham> By the spec, sure
  1334. # [19:02] <jgraham> browsers can have bugs ofc
  1335. # [19:02] <jgraham> If you want to ensure that they don't you'll have to test
  1336. # [19:02] * Joins: mdelaney (~mdelaney@67.218.107.27)
  1337. # [19:07] * Quits: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net) (Quit: xbuzz_)
  1338. # [19:08] * Joins: dave_levin (~dave_levi@74.125.59.65)
  1339. # [19:12] * Joins: agektmr (~Adium@nat/google/x-ahqkfgjxyaqqeywj)
  1340. # [19:12] * ako is now known as aho
  1341. # [19:16] * Quits: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net) (Quit: cying)
  1342. # [19:17] * Joins: jwalden (~waldo@63.224.145.184)
  1343. # [19:17] * Quits: matijsb (~matijsb@188.205.108.18) (Quit: Leaving.)
  1344. # [19:18] * Quits: Sumd (~zeta@host-241.123-43-115.dynamic.totalbb.net.tw) (Remote host closed the connection)
  1345. # [19:23] * Quits: teear (teear@84-231-62-52.elisa-mobile.fi) (Ping timeout: 264 seconds)
  1346. # [19:26] * Joins: teear (teear@84-231-36-118.elisa-mobile.fi)
  1347. # [19:27] * Joins: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net)
  1348. # [19:27] * Quits: othermaciej (~mjs@c-24-6-209-6.hsd1.ca.comcast.net) (Quit: othermaciej)
  1349. # [19:27] * Quits: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net) (Client Quit)
  1350. # [19:34] * Joins: TabAtkins_ (~tabatkins@nat/google/x-bjahcgzglqkiqemv)
  1351. # [19:39] * Quits: VISHAL (~VISHAL@122.179.131.53) (Ping timeout: 250 seconds)
  1352. # [19:39] * Quits: Kingdutch (~Kingdutch@188.200.149.217) (Ping timeout: 246 seconds)
  1353. # [19:44] * Joins: tw2113 (~tw2113@fedora/tw2113)
  1354. # [19:45] * Quits: davve__ (~davve@83.218.67.122) (Remote host closed the connection)
  1355. # [19:46] * Joins: weinig (~weinig@17.203.15.198)
  1356. # [19:47] * Joins: cooto (~Adium@190.98.195.170)
  1357. # [19:47] * Parts: cooto (~Adium@190.98.195.170)
  1358. # [19:49] * Joins: xtoph (~xtoph@213.47.185.206)
  1359. # [19:55] * Quits: mdelaney (~mdelaney@67.218.107.27) (Quit: mdelaney)
  1360. # [19:56] * Joins: foolip_ (~foolip@h242n6-g-hn-a11.ias.bredband.telia.com)
  1361. # [19:57] * Joins: Ms2ger (~Ms2ger@91.181.46.94)
  1362. # [19:57] * Quits: tbassetto (~tbassetto@92.103.127.226) (Quit: tbassetto)
  1363. # [20:02] * abarth is now known as abarth|gardener
  1364. # [20:02] * Quits: foolip_ (~foolip@h242n6-g-hn-a11.ias.bredband.telia.com) (Quit: Leaving)
  1365. # [20:05] * Quits: rimantas (~rimliu@93.93.57.193) (Quit: Leaving)
  1366. # [20:18] * Quits: Rik` (~Rik`@mozilla-paris-253-99.cnt.nerim.net) (Remote host closed the connection)
  1367. # [20:18] * Joins: dbaron (~dbaron@nat/mozilla/x-hnqlsfqulimmzyhn)
  1368. # [20:21] * Joins: zdobersek1 (~zan@cpe-46-164-6-127.dynamic.amis.net)
  1369. # [20:23] * Quits: zdobersek (~zan@cpe-46-164-29-246.dynamic.amis.net) (Ping timeout: 246 seconds)
  1370. # [20:25] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: Freedom - to walk free and own no superior.)
  1371. # [20:26] * Joins: Bass10 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  1372. # [20:26] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Quit: Reading http://davidwalsh.name)
  1373. # [20:26] * Joins: xbuzz_ (~chris@c-24-63-24-211.hsd1.ma.comcast.net)
  1374. # [20:28] * Joins: othermaciej (~mjs@67.218.106.89)
  1375. # [20:30] * Joins: zcorpan (~zcorpan@c-519de355.410-6-64736c14.cust.bredbandsbolaget.se)
  1376. # [20:30] * Joins: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com)
  1377. # [20:31] * Quits: micheil (~micheil@124-149-177-22.dyn.iinet.net.au) (Ping timeout: 264 seconds)
  1378. # [20:33] * Joins: potatis_invalido (~chatzilla@78-69-155-129-no176.tbcn.telia.com)
  1379. # [20:37] * Quits: othermaciej (~mjs@67.218.106.89) (Quit: othermaciej)
  1380. # [20:44] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Remote host closed the connection)
  1381. # [20:51] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  1382. # [20:53] * beowulf resents jgraham's suggestion that work must be done before cakes can be had
  1383. # [20:54] * Quits: davidhund (~davidhund@dnuhd.xs4all.nl) (Quit: davidhund)
  1384. # [20:54] * Joins: matijsb (~Adium@5353CD69.cm-6-4d.dynamic.ziggo.nl)
  1385. # [20:59] * Joins: othermaciej (~mjs@17.246.17.74)
  1386. # [21:02] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
  1387. # [21:07] * Quits: jeremyselier (~Jeremy@2a01:e35:2eec:80a0:fa1e:dfff:feec:469) (Ping timeout: 260 seconds)
  1388. # [21:07] * Joins: sephr (~Eli@c-98-235-63-240.hsd1.pa.comcast.net)
  1389. # [21:11] * Quits: tw2113 (~tw2113@fedora/tw2113) (Quit: Don't follow me)
  1390. # [21:14] * Quits: cpearce (~chatzilla@ip-118-90-94-177.xdsl.xnet.co.nz) (Ping timeout: 240 seconds)
  1391. # [21:19] <jgraham> There is cake?
  1392. # [21:19] * Quits: phrearch (~phrearch_@82-136-229-19.ip.telfort.nl) (Quit: Leaving)
  1393. # [21:20] <bfrohs> The cake is a lie.
  1394. # [21:25] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  1395. # [21:25] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Client Quit)
  1396. # [21:25] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  1397. # [21:31] * Joins: tw2113 (~tw2113@fedora/tw2113)
  1398. # [21:38] * Quits: agektmr (~Adium@nat/google/x-ahqkfgjxyaqqeywj) (Quit: Leaving.)
  1399. # [21:45] * Joins: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
  1400. # [21:53] * Joins: SteveGL (~dev@174-21-148-189.tukw.qwest.net)
  1401. # [21:55] * Quits: smaug____ (~chatzilla@cs181139127.pp.htv.fi) (Ping timeout: 240 seconds)
  1402. # [22:03] * Joins: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com)
  1403. # [22:12] * Joins: Martijnc (~Martijnc@91.176.231.15)
  1404. # [22:16] * Quits: xtoph (~xtoph@213.47.185.206)
  1405. # [22:16] * Joins: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6)
  1406. # [22:17] <zcorpan> hsivonen: you have access to the @whatwg twitter?
  1407. # [22:18] <zcorpan> hsivonen: wondered if you could RT https://twitter.com/zcorpan/status/53548207921315840 from @whatwg (or write a new tweet)
  1408. # [22:20] * Joins: karlcow (~karl@nerval.la-grange.net)
  1409. # [22:27] <antti_s> is there an offline html5 validator available? (other than a local instance of validator.nu)
  1410. # [22:27] <Ms2ger> That's the only one I know
  1411. # [22:28] <zcorpan> is there an html5 validator other than validator.nu?
  1412. # [22:30] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Quit: Reading http://davidwalsh.name)
  1413. # [22:30] * Joins: smaug____ (~chatzilla@cs181139127.pp.htv.fi)
  1414. # [22:33] * Joins: murz (~mmurraywa@wcproxy.msnbc.com)
  1415. # [22:34] * Joins: nessy (~Adium@124-168-15-54.dyn.iinet.net.au)
  1416. # [22:37] * Joins: cpearce (~chatzilla@203-97-204-82.dsl.clear.net.nz)
  1417. # [22:37] <karlcow> zcorpan: validator.w3.org but which is the same engine than validator.nu. I do not know another implementations of html5 validation. Unfortunately.
  1418. # [22:38] <zcorpan> yeah would be nice with some competition there - i'd like a validator that was tightly integrated with browser dev tools
  1419. # [22:39] <zcorpan> where clicking an error would bring up the relevant element in the dom tree view
  1420. # [22:40] * bfrohs misses his old validator/dev tool that did exactly that
  1421. # [22:41] <zewt> out of curiosity, when is that more useful than going to the corresponding source line?
  1422. # [22:42] <zcorpan> there might not be a source line if you're doing stuff with script
  1423. # [22:42] <zewt> i suppose if there were any in-place validators that could validate a DOM tree directly, eg. to validate dynamic content
  1424. # [22:43] <zcorpan> with today's web apps, what the validator sees is not so useful to validate
  1425. # [22:44] * weinig is now known as weinig|awayish
  1426. # [22:46] * Quits: miketaylr (~miketaylr@206.217.92.186) (Quit: miketaylr)
  1427. # [22:50] * Quits: msucan (~robod@89.123.146.211) (Quit: .)
  1428. # [22:52] <jgraham> By the time you have a DOM you missed half the errors anyway
  1429. # [22:52] <jgraham> Of course you can collect those up at the time
  1430. # [22:52] * Joins: kennyluck_ (~kennyluck@EM111-188-30-244.pool.e-mobile.ne.jp)
  1431. # [22:52] * Quits: stefan-_ (~music@trir-4d0d8fc6.pool.mediaWays.net) (Remote host closed the connection)
  1432. # [22:53] <zcorpan> sure, parse errors would be logged too
  1433. # [22:53] <karlcow> http://lists.w3.org/Archives/Public/www-archive/2011Mar/0016
  1434. # [22:53] <zcorpan> also those from innerHTML etc, which could point to the line of script where it occurred
  1435. # [22:54] <karlcow> DOM SpellChecker by Sean Palmer
  1436. # [22:54] * Quits: kennyluck (~kennyluck@EM114-48-207-191.pool.e-mobile.ne.jp) (Ping timeout: 260 seconds)
  1437. # [22:54] * kennyluck_ is now known as kennyluck
  1438. # [22:57] <zcorpan> karlcow: is that just thoughts or running code?
  1439. # [22:58] <karlcow> zcorpan: thoughts I think. But Sean Palmer is known to hack too. So I do not know if he tried
  1440. # [22:59] * Quits: aho (~nya@fuld-590c6bb4.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
  1441. # [23:01] * Quits: matijsb (~Adium@5353CD69.cm-6-4d.dynamic.ziggo.nl) (Quit: Leaving.)
  1442. # [23:02] * Quits: zdobersek1 (~zan@cpe-46-164-6-127.dynamic.amis.net) (Quit: Leaving.)
  1443. # [23:05] * Joins: cying (~cying@c-24-23-135-168.hsd1.ca.comcast.net)
  1444. # [23:06] * xbuzz_ is now known as xbuzz
  1445. # [23:09] * Quits: MikeSmith (~MikeSmith@EM114-48-22-161.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
  1446. # [23:09] * Quits: Martijnc (~Martijnc@91.176.231.15) (Quit: Martijnc)
  1447. # [23:09] * Joins: estes (~aestes@2620:0:1b00:1191:d69a:20ff:fed0:8cd2)
  1448. # [23:09] * Quits: Xano (~bart@524B818E.cm-4-4c.dynamic.ziggo.nl) (Quit: Beer o'clock!)
  1449. # [23:10] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Quit: mdelaney)
  1450. # [23:14] * Joins: MikeSmith (~MikeSmith@EM111-188-43-9.pool.e-mobile.ne.jp)
  1451. # [23:15] * Quits: jacobolus (~jacobolus@c-24-128-49-85.hsd1.ma.comcast.net) (Remote host closed the connection)
  1452. # [23:19] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  1453. # [23:21] * Joins: jeremyselier (~Jeremy@2a01:e35:139f:2c60:fa1e:dfff:feec:469)
  1454. # [23:35] * Quits: FastJack (~fastjack@dumpstr.net) (Read error: Operation timed out)
  1455. # [23:38] * Quits: KaOSoFt (~KaOSoFt@unaffiliated/kaosoft) (Quit: Liberty is the right to choose, freedom is the result of that choice.)
  1456. # [23:39] * Joins: FastJack (~fastjack@dumpstr.net)
  1457. # [23:46] * Quits: richardschwerdtf (~RichS@99-39-114-91.lightspeed.austtx.sbcglobal.net) (Quit: richardschwerdtf)
  1458. # [23:47] * Quits: Ms2ger (~Ms2ger@91.181.46.94) (Quit: nn)
  1459. # [23:56] * Joins: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  1460. # [23:58] * Quits: plainhao (~plainhao@208.75.85.237) (Quit: plainhao)
  1461. # [23:58] * Joins: plomlomp1m (~plomlompo@i59F6A1A8.versanet.de)
  1462. # Session Close: Fri Apr 01 00:00:00 2011

The end :)