/irc-logs / freenode / #whatwg / 2010-07-21 / end

Options:

  1. # Session Start: Wed Jul 21 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: Smylers (~smylers@host81-151-154-200.range81-151.btcentralplus.com) (Ping timeout: 245 seconds)
  4. # [00:01] <TabAtkins> We're arguing because Safari/Chrome treat it as just the dirtied pixels, and will probably have difficulty changing.
  5. # [00:01] <Philip`> "pixels dirtied" seems a difficult thing to define, when you can have transparent images and shadows and antialiasing
  6. # [00:02] <Hixie> not to mention that some of the path routines can result in conceptually near-infinite lines iirc
  7. # [00:02] <Philip`> The clipping region is finite so that doesn't seem like a problem
  8. # [00:04] <othermaciej> tabatkins: I believe the IE team prefers the Safari/Chrome interpretation of globalCompositeOperation
  9. # [00:04] <Philip`> TabAtkins: Compute the bounding box of the dirtied pixels, draw the shape onto a layer of that size, draw the layer onto the canvas, then draw some conceptually transparent-black rectangles (in an efficient way) over the rest of the clipping region?
  10. # [00:04] <othermaciej> I advised them to post about this, I do not know if they did
  11. # [00:05] <TabAtkins> Philip`: CoreGraphics does the dirtied-pixel thing, and Skia does the same (presumably for platform compat).
  12. # [00:06] <Philip`> TabAtkins: I don't see why it would be hard to emulate the spec behaviour
  13. # [00:06] <TabAtkins> Philip`: The spec's definition of globalCompositeOperation requires most methods other than the defualt source-over to recompute every pixel in the canvas.
  14. # [00:06] <Philip`> Only 4 of the methods, I think
  15. # [00:06] <Philip`> Oh, 5
  16. # [00:07] <Philip`> (The ones in http://philip.html5.org/tests/canvas/suite/tests/index.2d.composite.uncovered.html)
  17. # [00:07] <TabAtkins> the two in/outs, and destinatop-atop.
  18. # [00:07] <Philip`> In the common case (globalAlpha=1) the "recompute" is just "clear to 0"
  19. # [00:10] * Joins: daedb_ (~daed@78-72-108-100-no178.tbcn.telia.com)
  20. # [00:12] <TabAtkins> othermaciej: Who'd you talk to on IE, if you remember?
  21. # [00:12] * Quits: daedb (~daed@78-72-108-100-no178.tbcn.telia.com) (Ping timeout: 240 seconds)
  22. # [00:16] <Philip`> Oh, that's not just the common case
  23. # [00:16] <othermaciej> tabatkins: I think they ended up posting to the canvas api list that almost no one is on
  24. # [00:16] <Philip`> That's every case
  25. # [00:16] <Philip`> because the alpha multiplication happens before the compositing
  26. # [00:16] <Philip`> so I think if the composite mode is one of the 5 then you can always just clear the whole canvas before drawing onto it
  27. # [00:17] <othermaciej> tabatkins: http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0046.html
  28. # [00:17] <Philip`> which seems like it ought to be pretty trivial to implement
  29. # [00:17] <Philip`> (unless I'm missing something important)
  30. # [00:17] <othermaciej> they emailed us privately after that, not sure if I should say who specifically (they are sensitive about private communication at times)
  31. # [00:20] <jamesr> othermaciej: the reply to that email on public-canvas-api appears to say that roc is switching to match safari
  32. # [00:20] <jamesr> which presumably means the spec is also changing?
  33. # [00:20] <othermaciej> jamesr: sounds like the spec should probably switch, then, if it says the other thing or is ambiguous
  34. # [00:21] <Philip`> What does Safari do for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/571 ?
  35. # [00:21] * Philip` only has a Chromium on Linux which doesn't support shadows
  36. # [00:22] <zcorpan_> Philip`: i see just an image with the cats in safari
  37. # [00:22] <roc> jamesr: you misunderstand
  38. # [00:22] <jamesr> i think i do, the reply doesn't make much sense
  39. # [00:22] <roc> we have some bugs where we don't currently follow the spec
  40. # [00:23] <roc> particularly on Mac
  41. # [00:23] <roc> I have patches to fix those bugs so we follow the spec always
  42. # [00:23] <jamesr> Philip`: in firefox i see odd blue stuff on the left and cats on the right. in safari i just see some cats on the right
  43. # [00:23] <TabAtkins> Yeah, following the email in Pritchard's email suggests that the spec was revised *to the current text*, describing FF/Opera's behavior.
  44. # [00:23] <TabAtkins> It looks like Pritchard just totally misunderstood what the IE team email was talking about.
  45. # [00:23] <Philip`> jamesr: In Firefox it breaks because of image compositing bugs
  46. # [00:23] <jamesr> roc: ok. the post from the microsoft fellow was suggesting that the spec be changed, and then the reply implied that you were going to change firefox
  47. # [00:23] <roc> othermaciej is right that the IE team prefers the source-bounded (Safari/Chrome) approach
  48. # [00:23] <jamesr> so that reply is just wrong
  49. # [00:24] <Philip`> zcorpan_: Hmm, that seems odd
  50. # [00:24] <Philip`> zcorpan_: What do you get if you remove the shadow lines?
  51. # [00:24] <roc> jamesr: I actually think you're misunderstanding Charles' email, maybe
  52. # [00:25] <jamesr> Philip`: i don't think that it is as simple as "just clear the whole canvas before drawing onto it"
  53. # [00:25] <roc> I think Charles is just saying that the spec unambiguously defines the behavior of globalCompositeOperation, and that Firefox will change to follow the spec, which is true
  54. # [00:25] <TabAtkins> roc: Correct, we are (though I think it's because his email was phrased very badly).
  55. # [00:25] <roc> sure
  56. # [00:25] <zcorpan_> Philip`: then i get half the cats as blue and a blue rectangle below it
  57. # [00:25] * Quits: meandi (~meandi@dynadsl-080-228-79-143.ewetel.net) (Quit: Nettalk6 - www.ntalk.de)
  58. # [00:26] <jamesr> Philip`: you would have to calculate the compositing results, stick that somewhere (in a buffer on the side presumably), clear the canvas, then put the compositing results into the canvas
  59. # [00:26] <Philip`> jamesr: I think I should have said "just clear the whole region of the canvas which is outside the area you're drawing pixels into"
  60. # [00:26] <roc> the main problem with the Safari/Chrome(/IE?) approach is that you would need to add to the spec a definition of what the bounds of the source actually are, in all cases
  61. # [00:26] * Joins: ap_ (~ap@17.246.17.28)
  62. # [00:26] <roc> and no-one has done that
  63. # [00:26] <Philip`> jamesr: Yeah, but the buffer only needs to be the size of the dirtied pixels, not the whole canvas
  64. # [00:26] <roc> and it doesn't seem particularly easy
  65. # [00:26] <othermaciej> roc: would you or anyone else at Mozilla be likely to object to changing the spec to the Safari/Chrome/IE-preferred behavior (assuming it was well-defined)?
  66. # [00:26] <jamesr> it's not consistent in safari in all cases
  67. # [00:26] <roc> it may add considerable complexity to spec
  68. # [00:27] <jamesr> for example, imho drawing a circle should be the same as drawing an image that contains a circle with a transparent background
  69. # [00:27] <jamesr> currently they render differently in safari
  70. # [00:27] * Quits: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6) (Read error: Operation timed out)
  71. # [00:27] * ap_ is now known as ap
  72. # [00:27] * Quits: Smylers1 (~smylers@host81-151-158-29.range81-151.btcentralplus.com) (Remote host closed the connection)
  73. # [00:27] <TabAtkins> roc: Apparently, the definition is "for images [and other things drawn onto the canvas, suitably defined], dirty region is the size of the image. Everything else, it's all non-transparent pixels."
  74. # [00:27] * Quits: ap (~ap@17.246.17.28) (Client Quit)
  75. # [00:27] <TabAtkins> That's the definition that Safari/Chrome is using right now.
  76. # [00:27] <Philip`> zcorpan_: Okay, that's what I see in Chromium
  77. # [00:27] <TabAtkins> (Though the image case is dumb, for the reason that jamesr mentions.)
  78. # [00:28] <Philip`> TabAtkins: That doesn't seem to work for shadows
  79. # [00:28] <Philip`> If I'm not mistaken, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/571 really ought to at least draw some blue where the rectangle and image and shadow overlap
  80. # [00:28] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
  81. # [00:28] <TabAtkins> Philip`: Maybe not - we didn't look at shadows yet.
  82. # [00:28] * Joins: Smylers (~smylers@host81-151-158-29.range81-151.btcentralplus.com)
  83. # [00:29] * Quits: zcorpan_ (~zcorpan@pat.se.opera.com) (Quit: zcorpan_)
  84. # [00:29] <roc> TabAtkins: so you're saying that for the "copy" operator, for every pixel in the source with alpha > 0, the corresponding destination pixel is set to the source pixel, but for every pixel in the source with alpha == 0, the corresponding destination pixel is unchanged?
  85. # [00:29] <roc> that sounds very strange
  86. # [00:30] * Quits: boaz (~boaz@64.119.159.231) (Quit: boaz)
  87. # [00:30] <TabAtkins> I think so, yeah.
  88. # [00:30] * Quits: Rik` (~Rik`@213.41.141.234) (Remote host closed the connection)
  89. # [00:30] <roc> that doesn't match the behavior of any graphics library I know
  90. # [00:31] <TabAtkins> I'm not looking at it right now, but I think that's precisely what CG does.
  91. # [00:31] <Hixie> (also sounds far less efficient than just copying the data over)
  92. # [00:31] * TabAtkins goes to mock up that for himself to verify again.
  93. # [00:31] <roc> it's certainly not what cairo does
  94. # [00:31] <TabAtkins> Yeah, Cairo does all the composite operations correctly.
  95. # [00:32] <roc> I'm also not sure what you mean by "[and other things drawn onto the canvas, suitably defined]"
  96. # [00:34] <Philip`> TabAtkins: (I think it does copy wrong, at least in some version of Firefox on Linux)
  97. # [00:34] <TabAtkins> roc: I mean drawing video and such on. I haven't tested video drawing, but I suspect it's treated the same as image drawing.
  98. # [00:34] <roc> oh, you mean everything drawn with the drawImage API?
  99. # [00:35] <roc> In general, defining exactly what the source bounds are seems rather subtle. For example if you have a stroked path, the bounds can't just be the path bounds, they have to be inflated to include the stroke, but do you just include the stroke or the interior as well? What if the stroke is dashed? You can go with your definition, weird as it is, but it won't necessarily match what authors expect
  100. # [00:35] <roc> and it certainly won't match with what graphics libraries do, other than CG if what you say is correct
  101. # [00:36] <TabAtkins> Okay, yeah, copy is identical to source-over in CG and Skia.
  102. # [00:36] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 276 seconds)
  103. # [00:37] <roc> so pixels with alpha==0 are transferred to the destination?
  104. # [00:37] <TabAtkins> Yes.
  105. # [00:37] <roc> phew
  106. # [00:37] <roc> ok
  107. # [00:37] <TabAtkins> Wait.
  108. # [00:37] <Philip`> That's not what source-over does
  109. # [00:38] <TabAtkins> What I mean is that if I draw a red rectangle, set composite to "copy", then draw a partially overlapping blue circle, what I get is a red rectangle overlapped by a blue circle, exactly the same as source-over.
  110. # [00:38] <roc> othermaciej: if someone comes up with a proper definition for how source-bounded operators should behave, and that definition is simple and useful, then sure, we'd change
  111. # [00:38] <Hixie> and if someone comes up with a proper definition for how source-bounded operators should behave, and that definition is simple and useful, i'd be happy to spec it
  112. # [00:38] <Hixie> but so far nobody has
  113. # [00:38] <Hixie> so...
  114. # [00:39] <jamesr> otherwise, though, i'm not sure how we these composite operations will ever become interoperable
  115. # [00:39] <TabAtkins> roc: Okay, yeah, alpha=0 pixels are copied over. so it is different from source-over.
  116. # [00:39] <roc> TabAtkins: what if you fill the circle with a gradient which is completely transparent in some region, then what?
  117. # [00:40] * Philip` still doesn't see why WebKits can't emulate the Firefox/Opera/spec behaviour easily, which would achieve interoperability
  118. # [00:40] <roc> I refuse to believe that any graphics library would just drop the transparent region out of the source bounds
  119. # [00:40] <TabAtkins> The difference in behavior is completely described by CG/Skia doing the composite operation correctly, but in a *local* region rather than globally.
  120. # [00:40] <roc> TabAtkins: sure, but you need to precisely define the bounds of that local region. That is the entire issue.
  121. # [00:41] <TabAtkins> Right.
  122. # [00:41] <TabAtkins> Just clarifying what our behavior is. ^_^
  123. # [00:41] <roc> Philip`: it is quite easy. I did it for the cairo CoreGraphics backend.
  124. # [00:41] * Joins: gavin_ (~gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com)
  125. # [00:41] * Quits: gavin_ (~gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com) (Changing host)
  126. # [00:41] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  127. # [00:41] <jamesr> roc: where's the code?
  128. # [00:42] <jamesr> othermaciej: if you want to change this in coregraphics webkit ports then we'd change the skia backend to match
  129. # [00:43] <jamesr> of course microsoft also prefers the safari version, but they haven't proposed a tight definition of the source image bounds
  130. # [00:43] <Hixie> jamesr: chrome could also lead the way, no need to follow apple on this :-P
  131. # [00:43] <roc> I can accept that the source-bounded version is more intuitive for authors
  132. # [00:44] <jamesr> yeah i find the firefox behavior bizarre honestly. if i draw a 20x20 rectangle why would all the other pixels in the canvas change
  133. # [00:44] <TabAtkins> Hixie: We have to have the same behavior on both CG and Skia, so having Apple fix CG is just easier. ^_^
  134. # [00:44] <roc> although, sometimes results that are "more intuitive" are actually less intuitive if you look at them closely
  135. # [00:44] <Hixie> TabAtkins: lame :-P
  136. # [00:44] <jamesr> TabAtkins: i'm not suggesting that someone at apple be forced to do the work, i'm wondering if that would make sense for the other folks who ship coregraphics webkit ports
  137. # [00:44] <TabAtkins> I think the FF behavior is fine. It's just something you generally have to use backing canvases to take proper advantage of.
  138. # [00:45] <Philip`> jamesr: The other pixels would all change because you explicitly chose a composite operation that causes pixels to change :-)
  139. # [00:45] <TabAtkins> But backing canvases are already an established technique in <canvas> use, so that seems fine.
  140. # [00:45] <jamesr> i also think that it's likely nobody uses these modes given how non-interoperable the existing implementations are
  141. # [00:45] <Philip`> If you don't want that to happen, don't use those composite operations
  142. # [00:46] <TabAtkins> It would be somewhat nice to be able to spawn off a backing canvas directly from a single <canvas> tag, rather than creating and inserting a new canvas, but that can be fixed later.
  143. # [00:46] <roc> jamesr: my cairo-quartz code is here: https://bugzilla.mozilla.org/show_bug.cgi?id=522859
  144. # [00:47] <roc> the actual fix hasn't landed yet
  145. # [00:47] <roc> TabAtkins: you don't need to insert a temporary canvas anywhere
  146. # [00:48] <TabAtkins> roc: For some uses you do. Frex, if you already have an image, and you want to draw some lines over it with, say, source-atop. You can't just set globalCompositeOperation to source-atop and start drawing lines.
  147. # [00:48] <Hixie> TabAtkins: (why can't you just clone it?)
  148. # [00:48] <TabAtkins> WEll, actually, with source-atop you could.
  149. # [00:48] <roc> I mean you don't ned to insert it in the DOM
  150. # [00:48] <roc> from an implementors point of view, the current spec wins
  151. # [00:48] <TabAtkins> roc: Oh, for some reason I thought you needed to insert it into the document before it would work. Shrug.
  152. # [00:50] <roc> I'm pretty sure that if we went with a source-bounded approach and nailed down exactly what the source bounds are in all cases, all but possibly one implementation/port would need significant changes
  153. # [00:51] <jamesr> well, to implement the current spec also requires several implementations to make some changes (webkit/coregraphics webkit/skia and whatever IE has). i don't know if they would be significant in terms of code
  154. # [00:54] <jamesr> roc: do you have a d2d backend for canvas yet in firefox?
  155. # [00:54] <roc> yep
  156. # [00:54] <roc> I don't know how compliant it is with this stuff
  157. # [00:54] <roc> however
  158. # [00:55] <roc> D2D does not really support compositing modes at all
  159. # [00:55] <roc> you have to drop down to D3D/shaders
  160. # [00:55] <jamesr> presumably you'll hit the same issues the IE9 team has
  161. # [00:55] <roc> (in Gecko we don't have "canvas backends", there's just cairo which we use for everything)
  162. # [00:56] * Quits: micheil (~micheil@124-170-55-41.dyn.iinet.net.au) (Quit: micheil)
  163. # [00:58] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  164. # [00:59] <roc> jamesr: what issues are those?
  165. # [01:00] * Joins: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  166. # [01:01] <jamesr> well, to do something like fillRect() the most natural (to me) way to do that on a gfx card is to create a quad and draw it, using a fragment shader to implement the blending
  167. # [01:01] * Joins: sicking (~chatzilla@nat/mozilla/x-tkgboxermoynpfgb)
  168. # [01:02] <jamesr> but that doesn't work if you also have to do some composite operation on pixels that land outside the quad
  169. # [01:06] * daedb_ is now known as daedb
  170. # [01:06] <roc> that's probably why D2D doesn't support blend modes
  171. # [01:07] <roc> the thing is, in shaders you generally don't get to read the destination pixel
  172. # [01:07] <roc> so blend modes are a pain either way
  173. # [01:08] <jamesr> in gl there's a set of built in blend modes that conceptually work the same way
  174. # [01:09] * Joins: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams)
  175. # [01:09] <roc> true
  176. # [01:10] <roc> still
  177. # [01:11] <roc> in your example, you can just draw a quad that fills the entire clip rect
  178. # [01:11] <roc> anyway, just come up with the right spec and we can change
  179. # [01:15] <jamesr> do we have any idea what modes people really want to use?
  180. # [01:15] <TabAtkins> I doubt it. ^_^
  181. # [01:15] <jamesr> roc: to be honest i'm not sure the safari behavior is strictly speaking better
  182. # [01:16] <Hixie> you could pretty easily find out, just instrument the operator attribute in chrome and let it loose
  183. # [01:16] <jamesr> that might be biased behind if(WebKit) sniffing
  184. # [01:16] <jamesr> but that is a good idea
  185. # [01:16] <TabAtkins> Hixie: That could easily be biased towards "wtf why is this mode different in Chrome and Firefox?" issues.
  186. # [01:17] <TabAtkins> Though, still, maybe useful.
  187. # [01:17] <roc> we changed 'copy' from source-bounded to source-unbounded and got one bug filed against us, for some Chrome experiemnt
  188. # [01:17] <jamesr> if it turns out that nobody uses anything except for source-over then i'd suggest removing the other modes from the spec until someone wants to use them and then requiring that proposed modes have compatible implementations that browser vendors are happy with
  189. # [01:18] <jamesr> it sucks to have a big matrix of modes that do not interoperate at all without any evidence that people want them
  190. # [01:18] <roc> 'copy' is clearly used
  191. # [01:19] * Quits: roc (~roc@121.98.230.221) (Quit: roc)
  192. # [01:19] <TabAtkins> Hmm. 'copy' is equivalent to just clearing the canvas and then drawing onto it, right?
  193. # [01:20] * Quits: cyphase_ (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net) (Remote host closed the connection)
  194. # [01:21] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  195. # [01:22] * Joins: cyphase (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net)
  196. # [01:30] <othermaciej> tabatkins: I think copy is equivalent to srcover on top of a 0-alpha background but not totally sure w/o doing the math
  197. # [01:30] <TabAtkins> The spec description of 'copy' is just "draw A. B is ignored". Which seems to be precisely the same as clearing the canvas and drawing A.
  198. # [01:30] <TabAtkins> "Display the source image instead of the destination image."
  199. # [01:36] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Remote host closed the connection)
  200. # [01:36] * Joins: ako (~nya@fuld-4d00d7e3.pool.mediaWays.net)
  201. # [01:36] * Quits: aho (~nya@fuld-4d00d377.pool.mediaWays.net) (Ping timeout: 240 seconds)
  202. # [01:37] * Quits: dglazkov (~dglazkov@nat/google/x-mmiufarkkwidzwvi) (Ping timeout: 265 seconds)
  203. # [01:38] <othermaciej> it just copies the pixels
  204. # [01:38] <Hixie> TabAtkins: what's normative in that list is the Porter-Duff definitions, not the prose
  205. # [01:39] <othermaciej> it doesn't really matter if the background is cleared
  206. # [01:39] * Quits: erlehmann (~erlehmann@dslb-188-103-028-197.pools.arcor-ip.net) (Read error: Operation timed out)
  207. # [01:39] * Joins: erlehmann_ (~erlehmann@dslb-092-078-142-243.pools.arcor-ip.net)
  208. # [01:39] <jamesr> othermaciej: it does for regions outside the bounds of the source
  209. # [01:39] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
  210. # [01:40] <jamesr> (if you have a notion of bounds of the source)
  211. # [01:40] <TabAtkins> othermaciej: Right. I'm just saying that, if people are using 'copy', they can equivalently just clear the canvas (the usual trick is by doing a null-resize) then drawing as normal.
  212. # [01:40] <jamesr> TabAtkins: null-resize dumps all other state
  213. # [01:40] <jamesr> not quite the same
  214. # [01:40] <TabAtkins> jamesr: Ah, right. Forgot about that.
  215. # [01:41] <othermaciej> tabatkins: you might also not be copying over the whole canvas
  216. # [01:41] <othermaciej> (or is that what the globalCompositeOperation debate is about?)
  217. # [01:41] <jamesr> othermaciej: with copy you actually are
  218. # [01:41] <TabAtkins> Right, when clip regions are considered.
  219. # [01:41] <TabAtkins> othermaciej: That's what the debate is about. ^_^
  220. # [01:41] <othermaciej> that makes copy pretty useless
  221. # [01:41] <jamesr> a 'copy' is over the entire canvas (respecting clip region) in ffx
  222. # [01:42] <othermaciej> one way you may want to use it is to clone chunks of a canvas to tile, or to draw an image that you know has no alpha into some region in the canvas, but that is pretty useless if it clears the whole canvas
  223. # [01:43] <jamesr> for that you can set a clip
  224. # [01:46] <TabAtkins> Unrelated: goddammit we need different terms for "absolute or fixed position" and "absolute or fixed position or floating".
  225. # [01:51] <roc> actually I think coming up with a reasonable definition for source-bounded operators is easy
  226. # [01:51] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
  227. # [01:52] <roc> just do it
  228. # [01:53] <Hixie> i don't think "just do it" will pass by quality bar :-P
  229. # [01:53] <Hixie> s/by/my/
  230. # [01:53] * Joins: bentruyman (~bentruyma@c-71-194-42-115.hsd1.il.comcast.net)
  231. # [01:53] <roc> that was an instruction, not proposed specification text :-)
  232. # [01:54] <Hixie> TabAtkins: "positioned" and "out-of-flow"?
  233. # [01:54] <TabAtkins> Hixie: "positioned" includes relpos.
  234. # [01:54] <Hixie> oh right
  235. # [01:55] <TabAtkins> Floats are in-flow for any layout mode except static flow. But this isn't expressed anywhere. >_<
  236. # [01:56] <TabAtkins> (Whereas abspos/fixpos are out-of-flow for all layout modes.)
  237. # [01:57] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  238. # [01:57] <Hixie> yeah i have to admit i don't mind having to work on html5 instead of css :-P
  239. # [01:58] <estellevw> what is the shortest valid HTML5 document?
  240. # [01:58] <estellevw> <!DOCTYPE html><meta charset=utf-8><title>Ugliest</title><p>valid html5 file</p>
  241. # [01:58] <estellevw> is that valid? and if so, it the meta required?
  242. # [01:58] <TabAtkins> You don't *need* the meta.
  243. # [01:58] <jamesr> <!DOCTYPE html>
  244. # [01:58] <TabAtkins> Otherwise, yeah, valid.
  245. # [01:58] <jamesr> ?
  246. # [01:58] <TabAtkins> jamesr: No, you need a title.
  247. # [01:58] <TabAtkins> But you don't need anything in the body.
  248. # [01:59] <TabAtkins> So <!DOCTYPE html><title></title> is the shortest possible, iirc.
  249. # [01:59] <estellevw> thanks
  250. # [02:00] <Hixie> are we not counting iframe srdoc documents as HTML5 documents?
  251. # [02:00] <TabAtkins> Probably not?
  252. # [02:00] <TabAtkins> What requirements are dropped from @srcdoc?
  253. # [02:00] <Hixie> because teh shortest iframe srdoc document is the empty string, but it has to be in a srcdoc="" attribute. :-)
  254. # [02:00] <TabAtkins> Ah, kk.
  255. # [02:00] <Hixie> doctype and title are optional in those
  256. # [02:00] <Hixie> <!DOCTYPE html><title></title> is probably non-conforming though
  257. # [02:00] <TabAtkins> I didn't know you'd dropped the title requirement.
  258. # [02:01] * Quits: roc (~roc@203-97-204-82.dsl.clear.net.nz) (Read error: No route to host)
  259. # [02:01] <Hixie> since <title> represents the document's title, and the empty string isn't a good title
  260. # [02:01] <Hixie> and the spec says you have to use elements appropriately to be conforming
  261. # [02:01] <Hixie> :-P
  262. # [02:01] <TabAtkins> Valid by validator.nu. ^_^
  263. # [02:01] <TabAtkins> I'd say the empty string is a good title for the empty document.
  264. # [02:02] <Hixie> yeah i was thinking that as i was writing it
  265. # [02:03] * Quits: gratz|home (~gratz@gratz.gotadsl.co.uk) (Quit: Leaving)
  266. # [02:04] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
  267. # [02:05] <estellevw> :)
  268. # [02:06] <TabAtkins> <!DOCTYPE html><title>This document intentionally left blank</title>
  269. # [02:07] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 240 seconds)
  270. # [02:07] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
  271. # [02:09] * Quits: aroben (~aroben@unaffiliated/aroben) (Quit: aroben)
  272. # [02:13] * Quits: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  273. # [02:14] * Quits: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net) (Quit: zzzzz)
  274. # [02:15] * Joins: Lelu (~Is@unaffiliated/sirjoker)
  275. # [02:16] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
  276. # [02:19] * Parts: Lelu (~Is@unaffiliated/sirjoker)
  277. # [02:21] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  278. # [02:21] * Joins: wakaba_0 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  279. # [02:25] * Joins: wakaba_1 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  280. # [02:25] * Joins: wakaba_2 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  281. # [02:25] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
  282. # [02:26] * Quits: wakaba_0 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
  283. # [02:27] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
  284. # [02:28] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
  285. # [02:32] * Joins: kennyluck_ (~kennyluck@EM114-48-36-112.pool.e-mobile.ne.jp)
  286. # [02:35] * Quits: kennyluck (~kennyluck@EM111-188-32-100.pool.e-mobile.ne.jp) (Ping timeout: 240 seconds)
  287. # [02:35] * kennyluck_ is now known as kennyluck
  288. # [02:35] * Quits: bobchao (~cctw@112.105.101.98) (Quit: Leaving.)
  289. # [02:35] * Joins: bobchao (~cctw@112.105.101.98)
  290. # [02:38] * Joins: karlcow (~karl@nerval.la-grange.net)
  291. # [02:39] * Quits: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net) (Remote host closed the connection)
  292. # [02:45] * Quits: jlebar (~jlebar@nat/mozilla/x-bfpxlamhummpukhg) (Quit: Leaving)
  293. # [02:48] * Quits: kennyluck (~kennyluck@EM114-48-36-112.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
  294. # [02:52] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
  295. # [02:56] * Quits: bobchao (~cctw@112.105.101.98) (Quit: Leaving.)
  296. # [03:03] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
  297. # [03:03] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  298. # [03:17] * Quits: sicking (~chatzilla@nat/mozilla/x-tkgboxermoynpfgb) (Ping timeout: 276 seconds)
  299. # [03:21] * Quits: jwalden (~waldo@adsl-70-131-107-7.dsl.emhril.sbcglobal.net) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2.4/20100622203044])
  300. # [03:25] * Quits: jamesr (~jamesr@nat/google/x-zntwzaltphwnuiyg) (Quit: jamesr)
  301. # [03:28] * Quits: wakaba_2 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
  302. # [03:28] * Quits: wakaba_1 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
  303. # [03:29] * Joins: wakaba_ (~wakaba_@203-140-90-184.eonet.ne.jp)
  304. # [03:29] * Joins: wakaba_0 (~wakaba_@203-140-90-184.eonet.ne.jp)
  305. # [03:36] <AryehGregor> If you have a File object, can you slice it up into multiple Blobs if you want to fiddle with it and don't want the whole thing to be in memory at once?
  306. # [03:36] * Joins: jamesr (~jamesr@nat/google/x-ruqtncxyrebtmyej)
  307. # [03:39] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
  308. # [03:42] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  309. # [03:43] * Quits: dave_levin (~dave_levi@74.125.59.73) (Quit: dave_levin)
  310. # [03:47] * Quits: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36) (Quit: weinig)
  311. # [04:01] * Joins: erlehmann__ (~erlehmann@dslb-188-102-048-076.pools.arcor-ip.net)
  312. # [04:04] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Quit: ⌘Q)
  313. # [04:05] * Quits: erlehmann_ (~erlehmann@dslb-092-078-142-243.pools.arcor-ip.net) (Ping timeout: 264 seconds)
  314. # [04:18] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  315. # [04:21] * Quits: othermaciej (~mjs@17.246.16.89) (Quit: othermaciej)
  316. # [04:27] * Joins: bobchao (~cctw@DHCP-21061.iis.sinica.edu.tw)
  317. # [04:29] * Joins: justicefries (~gerred@c-67-173-239-97.hsd1.co.comcast.net)
  318. # [04:30] * Joins: kennyluck (~kennyluck@133.27.228.170)
  319. # [04:38] * Quits: justicefries (~gerred@c-67-173-239-97.hsd1.co.comcast.net) (Quit: justicefries)
  320. # [04:38] * Joins: miketaylr (~miketaylr@24.42.95.108)
  321. # [04:43] * Joins: m_W (~mwilcox56@c-68-38-230-216.hsd1.nj.comcast.net)
  322. # [04:46] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 246 seconds)
  323. # [04:52] * Quits: jamesr (~jamesr@nat/google/x-ruqtncxyrebtmyej) (Quit: jamesr)
  324. # [04:53] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  325. # [04:54] * Quits: wakaba_0 (~wakaba_@203-140-90-184.eonet.ne.jp) (Quit: Leaving...)
  326. # [04:55] * Quits: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  327. # [05:03] * Quits: MikeSmith (~MikeSmith@110.8.254.11) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
  328. # [05:07] * Quits: erlehmann__ (~erlehmann@dslb-188-102-048-076.pools.arcor-ip.net) (Quit: Ex-Chat)
  329. # [05:10] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
  330. # [05:16] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
  331. # [05:20] * Joins: micheil (~micheil@124-170-55-41.dyn.iinet.net.au)
  332. # [05:25] * Joins: MikeSmith (~MikeSmith@110.8.254.11)
  333. # [05:27] * Quits: MikeSmith (~MikeSmith@110.8.254.11) (Client Quit)
  334. # [05:27] * Joins: MikeSmith (~MikeSmith@110.8.254.11)
  335. # [05:34] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Ping timeout: 240 seconds)
  336. # [05:39] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
  337. # [05:42] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  338. # [05:42] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
  339. # [05:47] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 264 seconds)
  340. # [05:48] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  341. # [05:54] * ako is now known as aho
  342. # [06:09] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
  343. # [06:12] * Quits: aho (~nya@fuld-4d00d7e3.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
  344. # [06:26] * Quits: bzed (~bzed@devel.recluse.de) (Read error: Operation timed out)
  345. # [06:28] * Joins: bzed (~bzed@devel.recluse.de)
  346. # [06:34] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
  347. # [06:35] <micheil> Hixie: you about?
  348. # [06:38] <Hixie> yo
  349. # [06:39] * Quits: MikeSmith (~MikeSmith@110.8.254.11) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
  350. # [06:41] <micheil> Hixie: question.. on websockets
  351. # [06:41] <Hixie> sure
  352. # [06:41] <micheil> if I can remember exactly what it was >_>
  353. # [06:42] <micheil> oh, right, would it be an idea to change the client side interface to show if there was actually a problem contacting the websocket server
  354. # [06:42] <micheil> eg, if there's a proxy in the way that allows you to load the client, but you get a 403 when you try to access the ws server
  355. # [06:43] <micheil> so that this type of state can be handled in browser more correctly
  356. # [06:43] <Hixie> by interface, do you mean exposing to the JS, or exposing to the user?
  357. # [06:43] <micheil> exposing to the front-end developer
  358. # [06:44] <micheil> so, things that could be exposed: timeout, 403 etc.
  359. # [06:44] <micheil> but not actually expose what the error was on server
  360. # [06:45] <micheil> just if the client can't actually connect to server
  361. # [06:45] <micheil> and also if the client gets disconnected from server prematurely
  362. # [06:45] <micheil> eg, on a network connection such as WiFi on an iPhone
  363. # [06:46] <micheil> the user goes into say a tunnel, then there's no network coverage, it would be good to be able to check on the client side for this case
  364. # [06:46] <Hixie> do you mean to the developer, or to the script the developer writes?
  365. # [06:46] <micheil> so, really it's a case of problem between client and server connection, not a problem the server has with a connection
  366. # [06:46] <micheil> the script the developer writes.
  367. # [06:46] * Quits: micheil (~micheil@124-170-55-41.dyn.iinet.net.au) (Quit: micheil)
  368. # [06:46] <Hixie> it would be a security flaw to expose the network-level error status
  369. # [06:47] <Hixie> it would let you probe intranets, for example
  370. # [06:47] <Hixie> however, you can detect when the user's system goes offline entirely, by checking for body.ononline and body.onoffline
  371. # [06:49] * Joins: micheil (~micheil@124-170-55-41.dyn.iinet.net.au)
  372. # [06:49] <micheil> eg, new WebSocket(..); ws.addListener(...)
  373. # [06:49] <micheil> actually, that's another thing, why not use DOM Events?
  374. # [06:51] <franksalim> micheil, I am confused. where do you see addListener? Is that in node?
  375. # [06:51] <micheil> franksalim: no, I'm use to DOM events, that's why I wrote it
  376. # [06:52] <micheil> my bad
  377. # [06:52] <Hixie> micheil: we do use DOM Events
  378. # [06:52] <micheil> do you?
  379. # [06:52] <Hixie> yes
  380. # [06:52] <micheil> I see ws.onopen etc. everywhere?
  381. # [06:52] <Hixie> you can use either .onopen or you can attach an 'open' event listener
  382. # [06:52] <Hixie> (onopen is far easier of course)
  383. # [06:52] <micheil> ah
  384. # [06:53] <micheil> I don't think that's clearly documented then
  385. # [06:53] * Quits: riven (~riven@53518387.cable.casema.nl) (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.)
  386. # [06:53] <micheil> also. I may be writing a websocket client test suite, is there anything in particular I should make sure I include?
  387. # [06:53] <Hixie> the IDL clearly says "WebSocket implements EventTarget;"
  388. # [06:53] <micheil> hmm.. does the spec?
  389. # [06:54] <Hixie> the IDL is in the spec... so yes
  390. # [06:54] * micheil checks
  391. # [06:55] <Hixie> also everything is defined in terms of "Event Handler", etc
  392. # [06:55] <Hixie> this might be easier to see in the WHATWG complete spec (the web apps 1.0 spec), since all the stuff is cross-referenced there
  393. # [06:56] <micheil> okay, I'm probably also going to write some client side developer documentation, I'll be sure to include this.
  394. # [06:56] <micheil> (just because I doubt developers will really read a spec.)
  395. # [06:57] <Hixie> yeah the spec is written mainly for the implementors
  396. # [06:57] <micheil> yeah, like our selves
  397. # [07:01] <Hixie> ok i've changed the websocket protocol so that Sec-WebSocket-Protocol is now a space-separated list of tokens
  398. # [07:01] <Hixie> and you have to return one to connect
  399. # [07:01] <Hixie> rather than it being a single token you have to return
  400. # [07:01] <franksalim> will the protocol selected by the server exposed in the API?
  401. # [07:02] <franksalim> *be exposed
  402. # [07:02] <Hixie> yeah i added WebSocket.protocol for that
  403. # [07:02] <franksalim> that's pretty nice
  404. # [07:02] <micheil> Hixie: hmm.. so eg: Sec-WebSocket-Protocol: Proto1 Proto2 Proto3 ....
  405. # [07:02] <Hixie> yup
  406. # [07:03] <micheil> awesome
  407. # [07:03] <Hixie> in the constructor it's still just a single argument (space-separated string)
  408. # [07:03] <Hixie> so you do var ws = new WebSocket('ws://...', 'Proto1 Proto2 Proto3');
  409. # [07:03] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  410. # [07:04] <micheil> hmm..
  411. # [07:04] <micheil> I disagree there
  412. # [07:04] <franksalim> not WebSocket(url, proto1, proto2, proto3)?
  413. # [07:04] <micheil> we have an array type in js for a reason.
  414. # [07:04] <micheil> new WebSocket(url, protocols[] )
  415. # [07:04] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  416. # [07:06] <micheil> eg: var ws = new WebSocket("ws://localhost/", ["msgpack", "bson", "json"])
  417. # [07:06] <micheil> (where i'm actually using protocol to say what kind of message content encoding I have)
  418. # [07:06] <Hixie> i considered doing var ws = new WebSocket('ws://...', ['Proto1', 'Proto2', 'Proto3']);
  419. # [07:06] <micheil> why not?
  420. # [07:06] <micheil> it makes most sense to a front-end developer
  421. # [07:06] <Hixie> it would need changes to implementations
  422. # [07:07] <micheil> and the current doesn't?
  423. # [07:07] <micheil> if( Array.isArray(protocol)) { protocol = Array.prototype.join.call(protocol, " "); }
  424. # [07:07] <Hixie> only minor ones
  425. # [07:07] <micheil> not that hard to change.
  426. # [07:07] <franksalim> ...and using variable arity would prevent us from adding a meaningful third parameter
  427. # [07:08] <franksalim> but i would prefer not to have space separated strings in an API
  428. # [07:08] <micheil> I'd say that protocol can be either a string or array type
  429. # [07:08] <micheil> which is a perfectly decent way of declaring an API for a js interface, commonly used by developers
  430. # [07:09] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
  431. # [07:10] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Client Quit)
  432. # [07:10] <micheil> and then, if a browser doesn't support the array, then it throws an array of bad arguments
  433. # [07:10] <micheil> * throws an error
  434. # [07:10] <micheil> try {} catch(e) {} it, handle it appropriately / try again with string
  435. # [07:12] <franksalim> i hope developers will list meaningful protocols or start specifying new protocols on top of json instead of just sending a format like "json"
  436. # [07:13] <Hixie> i guess i could make it an array
  437. # [07:13] <Hixie> is anyone using that argument yet?
  438. # [07:13] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
  439. # [07:13] <micheil> no, not here
  440. # [07:13] <franksalim> Hixie, at least not widely. It is really going to be useful when there are public cross-origin websocket services, and there aren't many of those
  441. # [07:13] <micheil> I currently don't even support it on the server-side
  442. # [07:14] <micheil> there's actually two franksalim
  443. # [07:14] <franksalim> two is not many :-)
  444. # [07:14] <micheil> Pusher App and some one else.
  445. # [07:14] <micheil> as for Pusher, I speak with the developers regularly, and they subscribe to hybi, so changes should be good.
  446. # [07:15] <micheil> I'll try and contact the other company and get them to watch the list if they don't.
  447. # [07:15] <Hixie> i'll prod the browser vendors, see what they say
  448. # [07:15] <Hixie> if everyone's ok with changing, then i'm ok with it
  449. # [07:15] <Hixie> but for such a minor thing, i'm also happy to go with a space-separated list
  450. # [07:15] <Hixie> after all, that's what the protocol uses
  451. # [07:16] <micheil> protocol should never influence the browser implementation.
  452. # [07:16] <micheil> we want it easy enough for anyone to be able to write a client.
  453. # [07:16] <micheil> servers should still be easy, but require technical knowledge
  454. # [07:16] <micheil> reason: then you can have websockets as a service (Software as a Service anyone?)
  455. # [07:17] <Hixie> you mean write a script that uses websockets, right? as opposed to an actual websockets client
  456. # [07:17] <franksalim> writing a client to support one specified protocol requires technical knowledge, much less 2+ protocols and negotiation
  457. # [07:17] <micheil> Hixie: client as in say a chat app or something.
  458. # [07:17] <franksalim> i mean a protocol client for a protocol over websocket
  459. # [07:17] <micheil> so, application?
  460. # [07:18] <Hixie> right
  461. # [07:18] <Hixie> yeah dunno what you'd call it
  462. # [07:18] <Hixie> "script" maybe :-)
  463. # [07:18] <franksalim> protocol client
  464. # [07:18] <micheil> Hixie: I'll try to standardise on that from now on.
  465. # [07:18] <franksalim> or client
  466. # [07:18] <Hixie> subprotocol client maybe
  467. # [07:18] * micheil hates the word "script" it sounds so "script-kiddy-ish"
  468. # [07:18] <Hixie> "protocol client" sounds like the actual browser
  469. # [07:18] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  470. # [07:18] <micheil> application
  471. # [07:18] <franksalim> i'm not sure i like the term subprotocol. everything can layer on anything else
  472. # [07:18] <micheil> that works., no?
  473. # [07:19] <franksalim> xmpp/websocket is essentially the same protocol as xmpp/tcp
  474. # [07:19] <Hixie> micheil: yeah that works too
  475. # [07:19] <franksalim> Hixie, it is recursive. it is like the 'actual' browser :-)
  476. # [07:19] <micheil> actually, interesting thing, there's a webworkers implementation in Node.js that uses WebSockets as the underlying communication medium
  477. # [07:20] <franksalim> Hixie, it doesn't stop being a protocol just because it is in a soft layer
  478. # [07:20] <Hixie> franksalim: yeah
  479. # [07:20] <Hixie> franksalim: i just use "subprotocol" because it's easier to grep for in the spec :-)
  480. # [07:20] <micheil> also, from that other day Hixie, the time for websockets is seriously now. I've currently got two job opps where websockets are wanted.
  481. # [07:20] <Hixie> franksalim: (you'll notice i don't call it that in the protocol or the api)
  482. # [07:20] <micheil> one from a startup, one from a large well established company
  483. # [07:20] <franksalim> Hixie, that _should_ have also cleared up the intent of subprotocol vs. alternative upgrade framing, too
  484. # [07:21] <franksalim> (on HyBi)
  485. # [07:21] <Hixie> micheil: it would have been five years ago if we'd been at this stage then
  486. # [07:21] <Hixie> micheil: there's been pent-up demand for this for years
  487. # [07:21] <micheil> Hixie: five years ago, and I wouldn't have been here ;P
  488. # [07:21] <Hixie> franksalim: not sure what you mean
  489. # [07:21] <micheil> Hixie: infact.. five years, that's almost mid-webstandards movement, no?
  490. # [07:22] <franksalim> calling it subprotocol indicates layering not alternative framing syntax, i think. there was some misunderstanding about that
  491. # [07:22] <micheil> (not webstandards for browser, but for developers)
  492. # [07:22] <Hixie> "webstandards movement"?
  493. # [07:22] <Hixie> franksalim: ah, maybe
  494. # [07:22] <franksalim> someone should write a history book :-)
  495. # [07:22] <Hixie> franksalim: i didn't understand -- still don't understand -- many of the discussions on hybi
  496. # [07:23] <Hixie> i get the feeling there are two very distinct desires
  497. # [07:23] <Hixie> and yet we're working on the same protocol
  498. # [07:24] <franksalim> at least two
  499. # [07:24] <Hixie> yeah, maybe more
  500. # [07:24] <franksalim> although fewer now than when half the list was talking about reverse http
  501. # [07:25] <Hixie> i just wish that the people who aren't trying to design a trivially implementable TCP-for-browsers protocol would design their own protocol instead of trying to warp websockets to their needs
  502. # [07:29] <micheil> Hixie: actually, there's talk in the dev community that when websockets support high bit data, people want to use them for transporting everything like images & binary data
  503. # [07:29] <micheil> (by support, I mean, in both server and browser)
  504. # [07:30] <Hixie> yeah
  505. # [07:30] <Hixie> binary data over websockets should be available later this year, i expect
  506. # [07:30] <micheil> cool
  507. # [07:30] * micheil has his parser ready to do it, but isn't yet
  508. # [07:31] <micheil> Hixie: do you use something like svn or git to manage the document versions for the specs?
  509. # [07:31] <Hixie> svn
  510. # [07:31] <Hixie> svn.whatwg.org
  511. # [07:31] <micheil> could you publish the diffs?
  512. # [07:31] <Hixie> svn.whatwg.org/webapps/source specifically
  513. # [07:31] <Hixie> the repo is public
  514. # [07:31] * Quits: dbaron (~dbaron@nat/mozilla/x-qtdqkoxdoipuntoc) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  515. # [07:31] <Hixie> you can see the differs also at http://html5.org/tools/web-apps-tracker
  516. # [07:32] <Hixie> diffs, even
  517. # [07:32] * Quits: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  518. # [07:32] <micheil> yeah, that's not so awesome though :P
  519. # [07:32] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  520. # [07:32] <Hixie> (the web-apps-tracker page is what i use, personally, rather than svn directly)
  521. # [07:33] <micheil> Hixie: I'd go for git style patch files.
  522. # [07:33] <franksalim> i leave for a minute, and i see you've been talking about one of my favorite things: binary data over websockets
  523. # [07:33] <micheil> Hixie: could I have permission to actually mirror the document on github?
  524. # [07:33] <micheil> (they have a useful git -> svn thing)
  525. # [07:33] <micheil> or svn -> git
  526. # [07:34] <franksalim> that's when the subprotocol aspect will be _killer_
  527. # [07:34] <micheil> franksalim: agreed
  528. # [07:35] <Hixie> micheil: sure, feel free to do whatever. The doc is under the license shown at the top of the WHATWG spec, which is pretty liberal.
  529. # [07:36] <micheil> okay.
  530. # [07:39] * Quits: jaacob (~jaacob@67.170.138.140) (Ping timeout: 260 seconds)
  531. # [07:40] <micheil> Hixie: do you have a Github account by any chance?
  532. # [07:40] <Hixie> no
  533. # [07:40] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  534. # [07:40] <micheil> okay
  535. # [07:40] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  536. # [07:41] <micheil> Hixie: let me know if you ever create one, that way I can correctly get the attribution right
  537. # [07:41] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  538. # [07:41] <Hixie> k
  539. # [07:43] <micheil> just waiting on github to import it.
  540. # [07:43] <micheil> http://github.com/miksago/whatwg-webapps-mirror
  541. # [07:43] * Joins: jaacob (~jaacob@67.170.138.140)
  542. # [07:52] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 252 seconds)
  543. # [07:53] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  544. # [07:54] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
  545. # [08:01] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  546. # [08:12] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
  547. # [08:13] * Joins: myakura (d2e8220d@gateway/web/freenode/ip.210.232.34.13)
  548. # [08:14] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
  549. # [08:18] <myakura> http://f1results.socialminds.com.br/ uses <progress> and <meter> but i don't think it uses them in a conforming way.
  550. # [08:25] * Disconnected
  551. # [08:26] * Attempting to rejoin channel #whatwg
  552. # [08:26] * Rejoined channel #whatwg
  553. # [08:26] * Topic is 'WHATWG: http://www.whatwg.org/ -- logs: http://krijnhoetmer.nl/irc-logs/ -- stats: http://gavinsharp.com/irc/whatwg.html -- Please leave your sense of logic at the door, thanks!'
  554. # [08:26] * Set by annevk42 on Mon Oct 19 23:03:06
  555. # [08:26] * Quits: krijnh (~krijnhoet@83.160.77.30) (Read error: Connection reset by peer)
  556. # [08:29] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 276 seconds)
  557. # [08:29] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  558. # [08:37] * Joins: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl)
  559. # [08:39] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 245 seconds)
  560. # [08:43] * Joins: baba (~sallabanc@69.50.70.12)
  561. # [08:48] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Quit: robb1e)
  562. # [08:49] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
  563. # [08:49] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Client Quit)
  564. # [08:55] * Joins: Amorphous (jan@unaffiliated/amorphous)
  565. # [08:58] * Joins: boblet (~boblet@p47239-ipbffx02marunouchi.tokyo.ocn.ne.jp)
  566. # [09:01] * Quits: roc (~roc@203-97-204-82.dsl.clear.net.nz) (Quit: roc)
  567. # [09:03] * Quits: kennyluck (~kennyluck@133.27.228.170) (Quit: kennyluck)
  568. # [09:05] * Joins: davidhund (~davidhund@78-27-27-74.dsl.alice.nl)
  569. # [09:11] * Joins: kennyluck (~kennyluck@2001:200:1c0:2900:225:ff:fe4d:f8c7)
  570. # [09:11] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
  571. # [09:11] <baba> omg, so html5 isn't going to be official till 2022 probably?
  572. # [09:12] <Hixie> "official"?
  573. # [09:12] <baba> W3 Recommendation
  574. # [09:12] <Hixie> according to the W3C, it'll be a W3C recommendation before the end of september.
  575. # [09:12] <baba> W3C
  576. # [09:13] <micheil> Hixie: hmm.. "html5" vs ?
  577. # [09:13] <Hixie> (then again, according to the W3C, it'll be in last call before the end of June 2008, and it's still not in last call there)
  578. # [09:13] <baba> http://en.wikipedia.org/wiki/HTML5
  579. # [09:13] <micheil> would it be an idea to give a timeline guide as to when we can start using various things under the umbrella "html5"
  580. # [09:13] <baba> it says "Ian Hickson, editor of the HTML5 specification, expects the specification to reach the Candidate Recommendation stage during 2012, and become a W3C Recommendation in the year 2022 or later."
  581. # [09:13] <Hixie> baba: ah, yeah, my guess is it'll be a REC around then.
  582. # [09:14] <micheil> eg, WebSockets are available in some browsers from February 2010 onwards
  583. # [09:14] <Hixie> baba: not sure that that's a particularly interesting milestone though
  584. # [09:14] <Hixie> baba: REC for a Web spec at this point is basically when the technology dies
  585. # [09:14] <baba> lol
  586. # [09:14] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  587. # [09:14] * Quits: kennyluck (~kennyluck@2001:200:1c0:2900:225:ff:fe4d:f8c7) (Client Quit)
  588. # [09:14] <Hixie> that wasn't meant to be a joke :-)
  589. # [09:14] <Hixie> specs that are useful are in active maintenance
  590. # [09:15] <micheil> Hixie: agreed.
  591. # [09:15] <micheil> also, I like that there may be some drive behind some specs that they are being designed based off implementation
  592. # [09:16] <baba> Hixie, how are you/did you go about learning html5?
  593. # [09:17] <Hixie> well i basically wrote it
  594. # [09:17] <Hixie> so...
  595. # [09:17] <baba> http://www.w3schools.com/html5/default.asp ?
  596. # [09:17] <baba> what?
  597. # [09:17] <baba> really?
  598. # [09:17] <micheil> baba: yeah
  599. # [09:17] <Hixie> i guess i did it the hard way
  600. # [09:17] <baba> oh, speaking with the big boys, didn't know
  601. # [09:17] <Hixie> :-)
  602. # [09:17] <micheil> Hixie == Ian Hickson, the guy that writes a lot of the specs
  603. # [09:17] <Hixie> this is where the sausage is made
  604. # [09:17] <Hixie> well, this is where we talk about how the sausage is made
  605. # [09:17] <Hixie> it actually gets made in emacs
  606. # [09:18] <baba> gotcha
  607. # [09:18] <micheil> Hixie: and where we argue about how vim is better.
  608. # [09:18] <Hixie> pah
  609. # [09:18] <baba> lol
  610. # [09:18] <micheil> >_>
  611. # [09:18] <micheil> Hixie: how.. uh.. big is that svn repo?
  612. # [09:18] <baba> i'm waiting to graduate before i reinstall ubuntu
  613. # [09:18] <micheil> Hixie: github's been fetching it for the past 2-3 hours, I'm sure.
  614. # [09:18] <baba> forces me to play too much with customization
  615. # [09:19] <Hixie> micheil: there's only a few files in there, but one of them is 4MB and has >4000 revisions
  616. # [09:19] <micheil> or not. only 1.4hrs
  617. # [09:19] * Joins: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se)
  618. # [09:19] <Hixie> and the other main one is 5MB and has the same number of revisions
  619. # [09:19] <micheil> hmm..
  620. # [09:19] <micheil> k, so, like, 4000x4000+4000x5000+3000
  621. # [09:20] <micheil> so, uh, pretty damn massive.
  622. # [09:20] <Hixie> and i wasn't even using it for the first few years :-)
  623. # [09:20] <micheil> >_>
  624. # [09:21] <micheil> eh' hopefully the github guys won't lynch me for doing this.
  625. # [09:21] * Joins: kmq (~kmq@85.159.13.90)
  626. # [09:21] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  627. # [09:21] <Hixie> micheil: heh
  628. # [09:23] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  629. # [09:24] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
  630. # [09:24] <baba> so who forks the bill for html5 development?
  631. # [09:25] <Hixie> depends what you mean
  632. # [09:25] <Hixie> if you mean who pays for whatwg.org's hosting, i do
  633. # [09:25] <Hixie> if you mean who pays for the browser vendors to implement the spec, they pay the cost themselves
  634. # [09:26] <micheil> and if you mean who pays hixie to write them, well, Hixie ? :P
  635. # [09:26] <Hixie> if you mean who pays us to take part in the process, well, many of us are employed by various companies, and many others are just volunteers
  636. # [09:26] <baba> yeah, but Ian, who's compensating you for all your time developing the html5 specs
  637. # [09:26] <Hixie> i'm a google employee
  638. # [09:26] <baba> oh, didn't realize you still were
  639. # [09:26] <Hixie> and they pay me to work on this pretty much fulltime
  640. # [09:26] <micheil> but google's not the only party.
  641. # [09:26] <Hixie> before that opera paid me about 50% time to work on this
  642. # [09:26] <baba> guess it's to everyone's advantage to implement this
  643. # [09:26] <Hixie> but all the browser vendors are involved, as are many other companies
  644. # [09:26] <baba> including MS?
  645. # [09:27] <Hixie> and other organisations
  646. # [09:27] <Hixie> yup
  647. # [09:27] <baba> they send someone there to slow u down?
  648. # [09:27] <Hixie> the w3c html wg has been chaired by a microsoft person since inception
  649. # [09:27] * Quits: miketaylr (~miketaylr@24.42.95.108) (Ping timeout: 240 seconds)
  650. # [09:27] <micheil> while I don't do things financially, I'm an implementor of a few parts, so, I often ask questions & provide feedback
  651. # [09:27] <Hixie> (different person then than now, and they're not the only chair, but still, it's pretty high-profile involvement for microsoft)
  652. # [09:27] <micheil> and really, microsoft aren't slow, it's just adoption
  653. # [09:28] <micheil> I could say Firefox and Safari are slow, because they don't support WebSockets at draft76, but that'd be stupidity.
  654. # [09:28] <Hixie> microsoft have definitely not been responsible for any slowness in html5's development so far
  655. # [09:29] <micheil> and without implementation, a spec doesn't really mean much
  656. # [09:29] <baba> then why does IE always have issues
  657. # [09:29] <baba> with even the current standards
  658. # [09:29] * Joins: kennyluck (~kennyluck@133.27.228.170)
  659. # [09:29] <micheil> baba: even people who aren't microsoft don't do things to standards
  660. # [09:29] <Hixie> i gotta go to bed
  661. # [09:29] <Hixie> nn
  662. # [09:30] <baba> goodnight
  663. # [09:30] <micheil> Hixie: good point, it is 3am
  664. # [09:30] <micheil> Night'
  665. # [09:31] <baba> didn't mean to start a MS bashing session, just curious why I always have to adjust what I do so my css or whatever works on IE
  666. # [09:32] <micheil> baba: two words: corporate adoption
  667. # [09:32] <micheil> IE is such that if there's anything that's a massive change, the adoption is massively slow.
  668. # [09:33] <micheil> most government departments in australia, for instance, still use IE 6 or below
  669. # [09:33] <micheil> because there's ghosts from the browser wars.
  670. # [09:33] <estellevw> baba: lack of auto updating too
  671. # [09:34] <estellevw> if IE6 autoupdated to IE7, then to IE8, we wouldn't see 4% of people still using IE6
  672. # [09:34] <micheil> but then again, IE aren't the only ones that don't implement things correctly, for instance, Safari 5 doesn't handle the response handshake in websockets correctly
  673. # [09:34] <micheil> iirc,.
  674. # [09:35] <micheil> estellevw: you'd still have apps written to target IE6 which would need compleete rewrites to work on IE > 6, so, consequentially, IT admins disable automatic updates
  675. # [09:37] <baba> hmm, good point
  676. # [09:37] <baba> it does ask you to update though in windows
  677. # [09:37] <baba> ...btw, is there a solution for Pasting into the browser with html5?
  678. # [09:37] <baba> from the clipboard
  679. # [09:38] <baba> an image
  680. # [09:40] * Joins: zcorpan_ (~zcorpan@pat.se.opera.com)
  681. # [09:40] <micheil> umm.. no, but you could use I think the HTML5 drag and drop (only in some browsers)
  682. # [09:41] <micheil> morning zcorpan_
  683. # [09:41] <baba> hmm
  684. # [09:41] <baba> micheil, so flash is still the only solution for that?
  685. # [09:41] <micheil> flash isn't the only solution
  686. # [09:41] <micheil> and I'd say it's not a solution.
  687. # [09:42] <baba> mhtml
  688. # [09:42] * Joins: nessy (~Adium@124-168-156-153.dyn.iinet.net.au)
  689. # [09:42] <micheil> HTML has always had the <input type="file"> for a long long time
  690. # [09:42] <micheil> use it, it's there for a reason.
  691. # [09:42] <baba> but how about pasting from the clipboard
  692. # [09:42] <baba> an image from the clipboard
  693. # [09:42] <zcorpan_> morning micheil
  694. # [09:43] <micheil> baba: not possible.
  695. # [09:44] <baba> because there's still no where to store the image?
  696. # [09:44] <micheil> no
  697. # [09:44] <micheil> think about it, if you could programatically pull something from a visitors clip board, without their permission, then you'd have a big big security problem
  698. # [09:45] <baba> only if they choose to paste
  699. # [09:45] <micheil> but how do you know if they are pasting?
  700. # [09:45] <micheil> document.addEventListener("paste", fn) ?
  701. # [09:45] <micheil> I don't think so. What are they pasting into? a textarea, a canvas element, etc
  702. # [09:51] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  703. # [09:55] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Remote host closed the connection)
  704. # [09:55] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  705. # [09:58] <zcorpan_> Hixie: why did you ban U+0020 in subprotocol?
  706. # [10:00] <zcorpan_> Hixie: oh, nm
  707. # [10:00] <baba> micheil, just how you know if they are pasting text
  708. # [10:01] <micheil> baba: well, in Mozilla code base, I can actually listen for it
  709. # [10:01] <micheil> baba: via an API that's private to the Chrome (not accesible from pages), which is provided using a technology called XPCom
  710. # [10:01] <micheil> it's basically a C / C++ api accessor
  711. # [10:09] * Joins: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net)
  712. # [10:14] * Quits: boblet (~boblet@p47239-ipbffx02marunouchi.tokyo.ocn.ne.jp) (Quit: boblet)
  713. # [10:19] * Joins: foolip (~foolip@83.218.67.122)
  714. # [10:23] * Joins: phrearch (~phrearch_@82-136-229-19.ip.telfort.nl)
  715. # [10:23] <phrearch> hi
  716. # [10:23] * Joins: Smylers1 (~smylers@host86-163-20-223.range86-163.btcentralplus.com)
  717. # [10:24] * Quits: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams) (Quit: GarethAdams|Home)
  718. # [10:25] * Quits: Smylers (~smylers@host81-151-158-29.range81-151.btcentralplus.com) (Ping timeout: 245 seconds)
  719. # [10:26] <estellevw> when did <a> lose the ping attribute?
  720. # [10:26] <estellevw> or was i mistaken that it was ever there?
  721. # [10:26] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
  722. # [10:28] <estellevw> i see it http://www.w3.org/TR/2010/WD-html5-diff-20100624/ but not http://dev.w3.org/html5/markup/a.html
  723. # [10:31] <jgraham> estellevw: It lost it when people complained about it. It is still in the WHATWG copy though
  724. # [10:33] <estellevw> see it http://dev.w3.org/html5/html-author/#the-a-element too. Wondering if i should file a bug.
  725. # [10:33] * Joins: maikmerten (~maikmerte@port-92-201-94-144.dynamic.qsc.de)
  726. # [10:34] <hsivonen> the /html-author/ doc isn't active being worked on
  727. # [10:34] <hsivonen> I guess Lachy has been busy with other stuff
  728. # [10:35] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  729. # [10:35] * Joins: payman_s (~payman@77.72.99.119)
  730. # [10:37] <zcorpan_> yay hybi are +1ing
  731. # [10:38] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (*.net *.split)
  732. # [10:38] * Quits: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net) (*.net *.split)
  733. # [10:38] * Quits: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl) (*.net *.split)
  734. # [10:39] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
  735. # [10:39] * Joins: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net)
  736. # [10:39] * Joins: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl)
  737. # [10:41] * Joins: mat_t (~mattomasz@91.189.88.12)
  738. # [10:42] * Joins: ROBOd (~robod@89.123.178.63)
  739. # [10:42] <Lachy> hsivonen, I'm waiting to be assigned time to work on that stuff
  740. # [10:43] * Joins: Phae (~Phae@chimera.macmillan.com)
  741. # [10:44] * Joins: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  742. # [10:46] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  743. # [10:48] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 248 seconds)
  744. # [10:50] <baba> micheil, what I meant was, how come it's not dangerous for text to be able to be pasted in, but it is for images?
  745. # [10:50] * Joins: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk)
  746. # [10:52] * Quits: kennyluck (~kennyluck@133.27.228.170) (Quit: kennyluck)
  747. # [10:53] * Parts: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  748. # [10:54] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
  749. # [10:57] <micheil> baba: because, text is what it's always been
  750. # [10:58] <micheil> also, it's really quite complicated to handle any clipboard data, eg, how do you know what mime-type to show it with?
  751. # [11:03] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  752. # [11:05] * Quits: myakura (d2e8220d@gateway/web/freenode/ip.210.232.34.13) (Quit: Page closed)
  753. # [11:05] * Quits: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
  754. # [11:06] <baba> micheil, by trial-error?
  755. # [11:07] <micheil> too expensive to process.
  756. # [11:08] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  757. # [11:08] <baba> hmm
  758. # [11:08] <baba> how does flash do it?
  759. # [11:12] * Quits: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Remote host closed the connection)
  760. # [11:14] <micheil> no idea.
  761. # [11:16] <kbrosnan> http://www.adobe.com/livedocs/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00002187.html ?
  762. # [11:16] <baba> k
  763. # [11:16] <baba> oh wow
  764. # [11:16] <baba> thanks kbrosnan
  765. # [11:17] <baba> kbrosnan, question is, if there is an image in the clipboard, how does it know to paste an image
  766. # [11:17] <baba> how does it "check"
  767. # [11:17] <kbrosnan> no idea, just used $search_engine for flash clipboard api
  768. # [11:19] <baba> gotcha
  769. # [11:20] <jgraham> abarth: yt? The webkit parser tests Just Work now you have added them to the test directory. So that's fine.
  770. # [11:20] <abarth> jgraham: cool
  771. # [11:20] <jgraham> I don't know how to sync. What are your requirements
  772. # [11:20] <jgraham> ?
  773. # [11:20] <abarth> don't know
  774. # [11:21] <abarth> the question is whether we should continue to modify those files in the webkit tree
  775. # [11:21] <abarth> and upload them periodically
  776. # [11:21] <abarth> or whether you want the ability to edit them in the code.google.com repo
  777. # [11:21] <abarth> in which case we should probably make new dat files for new tests
  778. # [11:22] <jgraham> I am happy to not touch those files if you want to edit them locally and then periodically resync
  779. # [11:22] <abarth> ok, let's try that for a while
  780. # [11:23] <jgraham> I am also happy if you always edit in the html5lib repository and just resync to the webkit repository when needed
  781. # [11:23] <jgraham> But I guess that might be harder for you
  782. # [11:24] <abarth> jgraham: yeah, that doesn't integrate with our process that well
  783. # [11:24] <jgraham> OK
  784. # [11:27] <hsivonen> fwiw, I edit in html5lib first and then sync to mozilla-central
  785. # [11:27] <jgraham> (I guess the only problem is if you accidentially add buggy tests. In that case being able to make fixes fast is good.)
  786. # [11:28] * Quits: tyoshino (~tyoshino@220.109.219.244) (Read error: Connection reset by peer)
  787. # [11:28] <abarth> we're getting to the ned of implementing the parser, so we'll be done with these tests soon
  788. # [11:28] * Joins: tyoshino (~tyoshino@220.109.219.244)
  789. # [11:28] <abarth> the stuff i'm fixing now is fiddly webkit stuff that's not visible in the DOM
  790. # [11:29] <abarth> we also need to implement ian's latest round of changes to the spec
  791. # [11:29] * hsivonen spent the vast majority of time fixing Mochitests and Gecko stuff (as opposed to writing the parser core)
  792. # [11:29] <jgraham> Oh yeah, spec changes are another problematic case
  793. # [11:30] <jgraham> hsivonen: You implemented off-the-main-thread parsing at the same time, which I guess didn;t make it easier
  794. # [11:30] <jgraham> :)
  795. # [11:30] <hsivonen> jgraham: yeah, that, too
  796. # [11:30] * Quits: ukai (~ukai@220.109.219.244) (Ping timeout: 240 seconds)
  797. # [11:30] * Joins: ukai (~ukai@220.109.219.244)
  798. # [11:30] <abarth> we're down to 80 tests that have different expectations between the new and old parser
  799. # [11:30] <abarth> but we've been able to explain most of those differences
  800. # [11:30] <hsivonen> a big part of the mochitest failures arose from off-the-main-thread parsing
  801. # [11:31] <hsivonen> abarth: 80 tests makes me feel a bit better :-)
  802. # [11:31] <abarth> well, we used to fail some 15k tests
  803. # [11:31] <abarth> so it's a big improvement :)
  804. # [11:32] <abarth> hsivonen: i don't really understand off the main thread parsing
  805. # [11:32] <hsivonen> abarth: do you have HTML5-compliant about:blank timing?
  806. # [11:32] <abarth> dunno
  807. # [11:32] <abarth> probably not
  808. # [11:33] <hsivonen> I postponed that to after Firefox 4.0
  809. # [11:33] <abarth> how does one test taht?
  810. # [11:33] <hsivonen> so Gecko's about:blank currently isn't compliant
  811. # [11:33] <abarth> the problem with working on the parser is you need to decide where to stop implementing the spec
  812. # [11:33] <abarth> because, in principle, you could do the whole thing from that foundation
  813. # [11:33] <hsivonen> abarth: you poke the document of an iframe or of a window.open()ed window at various points in time to see what's there
  814. # [11:34] <abarth> oh, i'm sure that's not right
  815. # [11:34] <abarth> that stuff is crazy
  816. # [11:34] <abarth> the parser runs really slowly in debug mode
  817. # [11:34] <abarth> because we've loaded it up with so many asserts
  818. # [11:35] <abarth> we'll probably have to take a bunch of those out
  819. # [11:35] <abarth> which is kind of too bad
  820. # [11:35] <hsivonen> I'm planning on putting more asserts in :-)
  821. # [11:35] <hsivonen> currently, the Java asserts are carried over to C++, which isn't nice
  822. # [11:37] <abarth> ok, bed time for me
  823. # [11:38] <abarth> more triage in the morning :)
  824. # [11:38] * abarth is now known as abarth|zZz
  825. # [11:45] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: brb)
  826. # [11:48] * Joins: Rik` (~Rik`@213.41.141.234)
  827. # [11:51] * Quits: nessy (~Adium@124-168-156-153.dyn.iinet.net.au) (Quit: Leaving.)
  828. # [11:56] * Joins: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  829. # [11:58] <jgraham> Hmm some of these webkit tests seem to rely on scripting
  830. # [11:58] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
  831. # [12:01] * Quits: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
  832. # [12:04] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
  833. # [12:06] * Joins: mpt (~mpt@canonical/mpt)
  834. # [12:06] * Quits: masterov (~masterov@93.153.167.74) (Quit: masterov)
  835. # [12:09] * Joins: masterov (~masterov@93.153.167.74)
  836. # [12:09] * Joins: boblet (~boblet@zz2004300023769bf059.userreverse.dion.ne.jp)
  837. # [12:18] * Quits: foolip (~foolip@83.218.67.122) (Ping timeout: 240 seconds)
  838. # [12:25] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
  839. # [12:35] * Joins: mpt (~mpt@canonical/mpt)
  840. # [12:42] * Quits: wakaba_ (~wakaba_@203-140-90-184.eonet.ne.jp) (Ping timeout: 248 seconds)
  841. # [12:42] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  842. # [12:47] <karlcow> I wonder how many sites are sending the optional "Comment=comment" with cookies
  843. # [12:48] * Joins: foolip (~foolip@83.218.67.122)
  844. # [12:49] <Philip`> karlcow: Very few
  845. # [12:50] <Philip`> and half of them are Comment=Sun+ONE+Application+Server+Session+Tracking+Cookie and the other half are Comment=1-800-Volunteer.org
  846. # [13:03] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
  847. # [13:11] * Joins: miketaylr (~miketaylr@24.42.95.108)
  848. # [13:15] <hsivonen> what happened to being able to request more context in the Web Apps Tracker?
  849. # [13:17] <jgraham> hsivonen: I think anne removed it and waited to see if you complained
  850. # [13:18] <hsivonen> I'm complaining now
  851. # [13:19] <hsivonen> sooo...
  852. # [13:20] <hsivonen> suppose we have <svg><foreignObject><math><u>
  853. # [13:21] <hsivonen> the spec now says that upon <u>, you pop elements until either math or svg has been popped, switch to the secondary insertion mode and reprocess
  854. # [13:21] <hsivonen> is that really right?
  855. # [13:21] <hsivonen> hmm. maybe it is
  856. # [13:22] <hsivonen> but what about <math><annotation-xml><svg><u>
  857. # [13:22] <hsivonen> is it right in that case?
  858. # [13:22] <hsivonen> or in <svg><svg><u>
  859. # [13:22] <hsivonen> ?
  860. # [13:23] <hsivonen> I can't recall why I've implemented it in another way
  861. # [13:23] <hsivonen> but I've made it pop until the top of the stack is an HTML element
  862. # [13:25] <zcorpan_> hsivonen: seems it's not really right in all cases
  863. # [13:26] * Joins: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net)
  864. # [13:26] * Quits: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net) (Changing host)
  865. # [13:26] * Joins: aroben (~aroben@unaffiliated/aroben)
  866. # [13:26] <zcorpan_> hsivonen: the intent was to not pop so far for e.g. <svg><foreignContent><math><u>
  867. # [13:28] <zcorpan_> hsivonen: i guess the spec should revert that change or come up with something else that works better
  868. # [13:28] <hsivonen> sigh. http://html5.org/tools/web-apps-tracker?from=5154&to=5155 is going to result in another unreviewable patch for sicking to review
  869. # [13:29] * Joins: erlehmann (~erlehmann@dslb-188-102-048-076.pools.arcor-ip.net)
  870. # [13:30] * Joins: Martijnc (~Martijnc@91.176.127.112)
  871. # [13:30] <jgraham> hsivonen: I guess if there are bugs filing them with testcases that the revised spec should pass is the way forward
  872. # [13:32] * Quits: boblet (~boblet@zz2004300023769bf059.userreverse.dion.ne.jp) (Quit: boblet)
  873. # [13:32] <jgraham> This bit of the spec seems to be enormously fragile
  874. # [13:33] <jgraham> I'm not sure if there is something to learn from that
  875. # [13:34] * Joins: Matjas (5bb64371@gateway/web/freenode/ip.91.182.67.113)
  876. # [13:34] <zcorpan_> hsivonen: i reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=8966
  877. # [13:35] <Matjas> I have an input field ‘slug’ which indicates part of an URL that will be generated. I’d like to preview that URL. Which markup to use? <samp>http://domain.ext/<var>slug</var></samp>?
  878. # [13:36] <hsivonen> zcorpan_: thanks
  879. # [13:36] <Matjas> s/preview that URL/show a preview of that URL/
  880. # [13:36] <hsivonen> I wonder if it still holds that reprocessing an end tag token can never cause reprocessing in the 'in foreign content' mode...
  881. # [13:37] <Smylers1> Matjas: <var>slug</var> makes sense when you literally have the word ‘slug’ in there as a placeholder. But not for an actual slug.
  882. # [13:37] <zcorpan_> hsivonen: maybe we could have breakout bookmarks in the stack of open elements or so?
  883. # [13:38] <Matjas> Smylers1: I see. So as soon as it’s an actual slug, use <span> instead?
  884. # [13:38] <Matjas> Smylers1: Or is there a better alternative?
  885. # [13:38] <Smylers1> Why does it need anything?
  886. # [13:39] <Smylers1> If you wish it to be styled differently from the fixed part of the URL, you could use <b>.
  887. # [13:39] <Matjas> Smylers1: I’d like to use JS to dynamically change the preview based on the input, so I figured perhaps it would be a good idea to visually indicate the difference from the fixed URL part
  888. # [13:39] <Smylers1> <b> sounds right then.
  889. # [13:40] <hsivonen> zcorpan_: or maybe we should have the same scope check in this case that we have in the case where an end tags has been processed according to the rules of the secodary insertion mode
  890. # [13:40] <Smylers1> Or possibly <mark>, to highlight the part of the URL you're drawing readers' attention to.
  891. # [13:41] <Matjas> Smylers1: Oh yes, can’t believe I forgot about <mark>!
  892. # [13:41] <Matjas> Smylers1: And <samp> would be okay to use as a wrapper for the entire URL?
  893. # [13:41] <Smylers1> Those both have the advantage over <span> of conveying something even to users without CSS.
  894. # [13:41] <karlcow> Philip`: interesting thanks
  895. # [13:42] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
  896. # [13:42] <Smylers1> I've only ever considered <samp> for output of text-based programs, but it seems OK to use here too.
  897. # [13:42] <Smylers1> If you need anything at all there.
  898. # [13:47] <hsivonen> it's ridiculous how much http://html5.org/tools/web-apps-tracker?from=5154&to=5155 simplifies code
  899. # [13:55] * Quits: Matjas (5bb64371@gateway/web/freenode/ip.91.182.67.113) (Ping timeout: 252 seconds)
  900. # [13:58] * Quits: miketaylr (~miketaylr@24.42.95.108) (Remote host closed the connection)
  901. # [13:58] * Quits: bobchao (~cctw@DHCP-21061.iis.sinica.edu.tw) (Ping timeout: 265 seconds)
  902. # [14:00] * Joins: davidb_ (~davidb@mozca02.ca.mozilla.com)
  903. # [14:08] * Joins: FireFly (~firefly@unaffiliated/firefly)
  904. # [14:09] * Joins: mpt (~mpt@canonical/mpt)
  905. # [14:11] <jgraham> zcorpan_: Maybe it would be good to add the expected DOM trees to that comment?
  906. # [14:16] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  907. # [14:17] * aroben is now known as aroben|away
  908. # [14:19] * Joins: remysharp (~remysharp@vinov2.gotadsl.co.uk)
  909. # [14:19] * Joins: BlurstOfTimes (~blurstoft@168.203.117.112)
  910. # [14:19] * Quits: remysharp (~remysharp@vinov2.gotadsl.co.uk) (Remote host closed the connection)
  911. # [14:22] * Joins: remysharp (~remysharp@vinov2.gotadsl.co.uk)
  912. # [14:28] * Quits: bentruyman (~bentruyma@c-71-194-42-115.hsd1.il.comcast.net) (Quit: I will always love you.)
  913. # [14:30] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  914. # [14:31] * Joins: KaOSoFt (~maxzagato@190.24.156.162)
  915. # [14:31] * Quits: KaOSoFt (~maxzagato@190.24.156.162) (Changing host)
  916. # [14:31] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  917. # [14:31] * Quits: jmb (~jmb@login.ecs.soton.ac.uk) (Ping timeout: 240 seconds)
  918. # [14:36] <jgraham> """the amateur programmer requirement has been
  919. # [14:36] <jgraham> widely rejected"""
  920. # [14:36] <jgraham> that's news to me
  921. # [14:36] <jgraham> (re: websockets)
  922. # [14:37] <jgraham> Am I just not following along enough?
  923. # [14:38] <othermaciej> lots of people said they don't like it
  924. # [14:39] <othermaciej> I don't know if that counts as "widely rejected"
  925. # [14:40] * Joins: jmb (~jmb@login.ecs.soton.ac.uk)
  926. # [14:42] <hsivonen> Web specs also need to be resient against professionals who aren't careful enough
  927. # [14:48] * aroben|away is now known as aroben
  928. # [14:53] <jgraham> I wonder if it is worth my while saying that I believe in that requirement
  929. # [14:54] * Joins: miketaylr (~miketaylr@38.117.156.163)
  930. # [14:54] * Quits: zcorpan_ (~zcorpan@pat.se.opera.com) (Quit: zcorpan_)
  931. # [14:55] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
  932. # [14:55] * Joins: miketaylr (~miketaylr@38.117.156.163)
  933. # [15:12] * Joins: bobchao (~cctw@112.105.101.98)
  934. # [15:15] * Quits: mpt (~mpt@canonical/mpt) (Quit: Ex-Chat)
  935. # [15:24] * Quits: remysharp (~remysharp@vinov2.gotadsl.co.uk) (Remote host closed the connection)
  936. # [15:28] <jgraham> There is no reason I am missing that <!DOCTYPE potato SYSTEM 'taco"'> should parse to anything other than a DOCTYPE with name html and system id taco" is there?
  937. # [15:29] <jgraham> s/html/potato/
  938. # [15:30] <jgraham> These webkit tests seem to assume no public id or system id, but I think they are wrong
  939. # [15:30] * Quits: hendry (~hendry@webconverger.org) (Ping timeout: 260 seconds)
  940. # [15:32] <gsnedders> jgraham: Yeah, the rest is as the DOCTYPE is created (i.e., the public identifier is missing)
  941. # [15:32] <jgraham> Yeah I think the html5lib format doesn't distinguish missing from empty string
  942. # [15:35] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  943. # [15:36] <hsivonen> what's the best way to search one's own tweets?
  944. # [15:37] <jgraham> hsivonen: I thought it was a write-only medium...
  945. # [15:37] <hsivonen> apparently inurl: on Google
  946. # [15:39] <jgraham> Does http://search.twitter.com/advanced do what you want? I don't know if it time-limits...
  947. # [15:40] <jgraham> (but possibly the answerr to "best" is "have a local backup that can be conveniently grepped")
  948. # [15:41] <jgraham> That search page seems to be useless...
  949. # [15:43] <hsivonen> jgraham: nope, it doesn't do what I want
  950. # [15:43] <hsivonen> I wanted to find the tweet I mentioned in my latest email to the whatwg list
  951. # [15:46] <Lachy> is there a way on twitter to extract your entire history of tweets in one long file?
  952. # [15:47] <gsnedders> No, you can only get a three-digit number at a time
  953. # [15:53] * Joins: wakaba (~wakaba@35.72.102.121.dy.bbexcite.jp)
  954. # [15:54] * Joins: wakaba_ (~wakaba@35.72.102.121.dy.bbexcite.jp)
  955. # [15:54] * Quits: wakaba_ (~wakaba@35.72.102.121.dy.bbexcite.jp) (Client Quit)
  956. # [15:54] * Joins: hendry (~hendry@webconverger.org)
  957. # [15:54] * Joins: smaug___ (~chatzilla@cs181150024.pp.htv.fi)
  958. # [15:58] <Smylers1> Lachy: http://tweetbackup.com/ will do that.
  959. # [15:58] * Joins: smaug_ (~chatzilla@cs181150024.pp.htv.fi)
  960. # [15:59] <Smylers1> Sign up, using Twitter's oauth, then you can get an export of all your tweets in a text file (including tweets from before you signed up).
  961. # [16:00] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  962. # [16:01] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  963. # [16:04] <Lachy> Smylers1, thanks. Trying it out now.
  964. # [16:04] <Lachy> hopefully I have fewer than 3200 posts, which seems likely given my relatively infrequent usage
  965. # [16:22] <erlehmann> „So I heard you like Ogg, so i implemented it to toll you that I haven't implemen- OH WAIT :D“
  966. # [16:25] * Joins: plainhao (~plainhao@mail.xbiotica.com)
  967. # [16:26] <Lachy> erlehmann, where is that quote from?
  968. # [16:27] <erlehmann> Lachy, I invented it after reading mike shavers suggestion on the list that implementors should implement basic ogg support to determine if it is ogg to then tell that they do not support it.
  969. # [16:30] <jgraham> A warning that you're about to open a 5MB "text" document might be
  970. # [16:30] <jgraham> humane anyway.
  971. # [16:30] <jgraham> (Mike Shaver)
  972. # [16:31] <jgraham> Yeah "Warning: you appear to be reading the HTML5 spec. Are you sure you want to continue? (y/n)"
  973. # [16:31] * Joins: doublec (~doublec@li30-216.members.linode.com)
  974. # [16:31] * Joins: mpt (~mpt@conference/ubuntu/x-hmxavrpmvahhrcuq)
  975. # [16:31] * Quits: mpt (~mpt@conference/ubuntu/x-hmxavrpmvahhrcuq) (Changing host)
  976. # [16:31] * Joins: mpt (~mpt@canonical/mpt)
  977. # [16:31] <jgraham> I guess it is strictly html rather than text, but that doesn't obviously make it better...
  978. # [16:33] <erlehmann> jgraham, i thought that too. after all, with text/html, its major type is "text" ;)
  979. # [16:33] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  980. # [16:34] * Joins: kennyluck (~kennyluck@EM114-48-72-43.pool.e-mobile.ne.jp)
  981. # [16:35] <erlehmann> I hereby humbly suggest that "HTML5 spec" should now be abbreviated as "HTML5MB".
  982. # [16:35] <jgraham> We could just version it according to size
  983. # [16:35] <erlehmann> BRILLIANT
  984. # [16:35] <jgraham> Once it reaches 6Mb it is HTML6
  985. # [16:36] <jgraham> (cutting stuff out could be a problem of course)
  986. # [16:36] <erlehmann> http://www.nioutaik.fr/images/galerie/brilliant.jpg
  987. # [16:37] <jgraham> hsivonen: Do you remember what was decided about coalescing adjacent character tokens in cases like <table>a<tr></tr>b ?
  988. # [16:38] <jgraham> Oh I found it
  989. # [16:38] <jgraham> The spec says not to coalese
  990. # [16:38] <jgraham> hsivonen: Do you agree with the spec? :)
  991. # [16:39] <jgraham> (it seems that Mimefield disagrres with the spec)
  992. # [16:39] <jgraham> *disagrees
  993. # [16:44] <erlehmann> Mimefield. Hehe.
  994. # [16:44] <erlehmann> The silent browser!
  995. # [16:44] <gsnedders> All I'm saying <http://gsnedders.html5.org/html5.txt> is a number of megabytes of text
  996. # [16:45] <jgraham> Oh, that is a horrible typo
  997. # [16:47] <hsivonen> jgraham: it was easier to implement coalescing in all cases than to special-case something
  998. # [16:48] <jgraham> hsivonen: That is my feeling too. But webkit appear to be implementing coaleascing
  999. # [16:48] <hsivonen> jgraham: so I guess I disagree with the spec until someone demonstrates that this is an actual DoS-by-author-incompetence problem against Gecko
  1000. # [16:48] <hsivonen> (there are other ways to mount deliberate DoS attacks on Gecko)
  1001. # [16:48] <hsivonen> jgraham: do you mean non-coalescing?
  1002. # [16:48] <jgraham> hsivonen: Yes
  1003. # [16:48] <Philip`> What about deliberate DoS attacks on other users of the parser, e.g. the validator?
  1004. # [16:49] <hsivonen> Philip`: the validator uses SAX, so the question isn't applicable
  1005. # [16:49] <Philip`> Ah
  1006. # [16:49] <hsivonen> Philip`: and, IIRC, the Java tree builders don't coalesce, but my memory may be failing
  1007. # [16:50] <hsivonen> Coalescing in Gecko is needed, because there are discretionary flushes
  1008. # [16:50] <hsivonen> and because there's document.write
  1009. # [16:50] <hsivonen> hooray to document.write
  1010. # [16:58] * Joins: dglazkov (~dglazkov@nat/google/x-hixrgixedkmznwqf)
  1011. # [16:58] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  1012. # [16:59] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  1013. # [17:00] * Joins: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36)
  1014. # [17:00] <hsivonen> huh? so mkv doesn't have a magic within a constant amount of bytes
  1015. # [17:00] <hsivonen> that seems like a terrible design decision
  1016. # [17:01] <jgraham> hsivonen: Is the hadling of whitespace characters in the table text mode a) different from the spec and b) if so, deliberate?
  1017. # [17:02] <jgraham> It seems different to me, but I guess I could be confused
  1018. # [17:02] <jgraham> e.g. in <TABLE><center><font>a</center> <img> <tr><td></td> </tr> </table>
  1019. # [17:03] <hsivonen> jgraham: not deliberate if actually different
  1020. # [17:04] <jgraham> hsivonen: It seems to me that the spec requires hat whitespace-only text is not foster parented but only inserted into the current node
  1021. # [17:04] <jgraham> *that
  1022. # [17:05] <jgraham> Gecko seems to foster parent
  1023. # [17:05] <jgraham> But I might be missing something crucial
  1024. # [17:05] * Quits: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl) (Quit: Disconnected...)
  1025. # [17:06] <erlehmann> hsivonen, i would like to see the design rationale for the webm container :/
  1026. # [17:07] <Lachy> hsivonen, MKV always has the EBML magic number in the first 4 octets. It's just the doctype that can vary slightly in position, depending on the presence of some other EBML header elements
  1027. # [17:08] <foolip> right, sniffing it is not difficult
  1028. # [17:11] * Joins: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp)
  1029. # [17:12] <Lachy> foolip, has google changed their mind about insisting on the right mime type for webm, despite insisting to us long ago that they would only support webm with the right type?
  1030. # [17:13] <foolip> Lachy, I guess they never checked the MIME type at all, it's just used for canPlayType
  1031. # [17:13] <foolip> I tested an Ogg video with the wrong MIME type, but it's hard to imagine it's different for WebM
  1032. # [17:13] <erlehmann> weird
  1033. # [17:14] <foolip> perhaps they've fixed it in their snapshots, but I doubt that too
  1034. # [17:14] <Lachy> oh, wtf? I'm sure I mentioned that bug to them on sea otters, and I assumed they would fix it
  1035. # [17:14] <foolip> are any of the Chrome engineers actually active on the lists?
  1036. # [17:14] <foolip> It'd be easier to not have to guess
  1037. # [17:15] <foolip> or, um, test it yourself, I mean :)
  1038. # [17:19] <AryehGregor> Sea otters?
  1039. # [17:20] <AryehGregor> (also, Chrome developers are active in #chromium and #webkit, in my experience)
  1040. # [17:20] <foolip> AryehGregor, a private list prior to the public launch of WebM
  1041. # [17:20] <AryehGregor> Oh.
  1042. # [17:20] <AryehGregor> Fascinating.
  1043. # [17:23] * Quits: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
  1044. # [17:24] * Joins: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp)
  1045. # [17:24] <hsivonen> do Carakan and Nitro support JITting to PPC?
  1046. # [17:24] <AryehGregor> MikeSmith, is it supposed to be "crackles" or "cackles"? When I Googled it I found both, but "cackles" makes much more sense to me.
  1047. # [17:26] <MikeSmith> AryehGregor: dunno.. could be I typed it in wrong, or could be that it's ambiguous in John Clare's manuscript, and different editors transcribe it differently
  1048. # [17:26] * MikeSmith checks now
  1049. # [17:27] <MikeSmith> my Norton Anthology of Poetry has "crackles"
  1050. # [17:28] <hsivonen> looks like Carakan has PPC support
  1051. # [17:28] <MikeSmith> AryehGregor: which I like better than "cackles", even if it makes less sense
  1052. # [17:28] <MikeSmith> AryehGregor: I think Clare was in an insane asylum when he wrote that poem
  1053. # [17:29] <AryehGregor> In that case, the less sane one is probably correct, and the more sane one probably arose due to some helpful person like me assuming a copyist made a mistake.
  1054. # [17:29] <foolip> hsivonen, I doubt it produces PPC machine code, on PPC it ought to be running the interpreter only
  1055. # [17:29] * Quits: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp) (Read error: Connection timed out)
  1056. # [17:29] <AryehGregor> (this is a general principle when reconciling variant texts, the one that makes less sense is probably correct)
  1057. # [17:29] <jgraham> hsivonen: Carakan doesn't do JIT/PPC
  1058. # [17:29] * Joins: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp)
  1059. # [17:29] <jgraham> I wonder if V8 works at all on PPC
  1060. # [17:30] <jgraham> Because it doesn't have an interpreter
  1061. # [17:30] <foolip> it doesn't?
  1062. # [17:30] <foolip> can it run on ARM?
  1063. # [17:30] <jgraham> foolip: Yeah, they have ARM support
  1064. # [17:30] <foolip> well, that seems less insane then :)
  1065. # [17:31] <jgraham> (for people not keeping up, Carakan also has JIT-for-ARM: http://labs.opera.com/news/2010/07/21/ )
  1066. # [17:32] <MikeSmith> AryehGregor: yeah -- even with sane poets, overzealous editors have "corrected" a lot of stuff they would have been better left untampered with
  1067. # [17:32] <hsivonen> jgraham, foolip: oh, ok. Lots of misleading reporting about PPC and Carakan then
  1068. # [17:32] * Quits: kmq (~kmq@85.159.13.90) (Quit: WeeChat 0.2.6.3)
  1069. # [17:32] <jgraham> hsivonen: What are you reading?
  1070. # [17:32] <hsivonen> Nitro assembler source code doesn't appear to have PPC support
  1071. # [17:33] * Quits: karlushi (~karlushi@fw.vdl2.ca) (Ping timeout: 265 seconds)
  1072. # [17:34] <hsivonen> jgraham: C|Net
  1073. # [17:34] <hsivonen> jgraham: but looing closer, they didn't say JIT
  1074. # [17:34] <hsivonen> just put Caracan and PPC in the title
  1075. # [17:35] <hsivonen> so no one has a JS JIT for PPC?
  1076. # [17:35] <foolip> developing that would be a waste of time
  1077. # [17:35] <foolip> PPC is going away
  1078. # [17:35] <hsivonen> curiously, Nitro assembler has a MIPS back end
  1079. # [17:36] <jgraham> hsivonen: I hear MIPS is used on some devices, but I have no idea what (actually I know nothing about it)
  1080. # [17:36] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
  1081. # [17:36] <AryehGregor> Why do you care about JITing to PPC?
  1082. # [17:37] <Philip`> Maybe you want fast JavaScript in a web browser on a games console
  1083. # [17:37] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  1084. # [17:37] <AryehGregor> JIT to Cell!!!
  1085. # [17:38] <hsivonen> AryehGregor: I don't really *care*. I'm just curious.
  1086. # [17:38] <Philip`> AryehGregor: Cell is kind of just PPC plus some extra data processing units
  1087. # [17:39] <AryehGregor> Maybe everyone should JIT to LLVM and thus support everything that does. (Note: LLVM seems to be some new trendy technology, so it's appropriate for me to advocate it without understanding whether it would be remotely appropriate for this purpose)
  1088. # [17:39] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  1089. # [17:40] * Joins: pauld (~chatzilla@194.102.13.2)
  1090. # [17:41] * Quits: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk) (Quit: akamike)
  1091. # [17:42] * Joins: justicefries_ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net)
  1092. # [17:43] * Quits: davidhund (~davidhund@78-27-27-74.dsl.alice.nl) (Quit: davidhund)
  1093. # [17:43] * Philip` supposes Opera could care, because the Wii is PPC and it'd be nice if you could play JS games in Opera on there
  1094. # [17:44] * Quits: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se) (Remote host closed the connection)
  1095. # [17:47] * Joins: justicefries__ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net)
  1096. # [17:48] * Quits: justicefries_ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net) (Ping timeout: 240 seconds)
  1097. # [17:50] * Quits: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net) (Read error: Connection reset by peer)
  1098. # [17:55] <hsivonen> https://bugzilla.mozilla.org/show_bug.cgi?id=579846 hooray for abstraction layer violations
  1099. # [17:56] <hsivonen> Hixie: is it intentional that caching related pragmas aren't in HTML5?
  1100. # [18:01] * Joins: justicefries_ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net)
  1101. # [18:01] * Joins: jlebar (~jlebar@nat/mozilla/x-pjadbvlxwhxzbnxl)
  1102. # [18:02] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  1103. # [18:02] * Quits: justicefries__ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net) (Ping timeout: 240 seconds)
  1104. # [18:04] * Quits: justicefries_ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net) (Client Quit)
  1105. # [18:12] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
  1106. # [18:15] * KaOSoFt is now known as AndresBotero
  1107. # [18:23] <Hixie> hsivonen: only insofar as i was trying to keep it to a mininmum. If it's compat-needed, file a bug, I'll add whatever you say is needed.
  1108. # [18:23] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 245 seconds)
  1109. # [18:23] * Joins: jwalden (~waldo@adsl-70-131-107-7.dsl.emhril.sbcglobal.net)
  1110. # [18:29] * Joins: pauld (~chatzilla@194.102.13.2)
  1111. # [18:32] * Quits: Rik` (~Rik`@213.41.141.234) (Remote host closed the connection)
  1112. # [18:35] * Quits: Phae (~Phae@chimera.macmillan.com) (Quit: Leaving.)
  1113. # [18:39] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
  1114. # [18:39] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Quit: ⌘Q)
  1115. # [18:40] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  1116. # [18:43] * workmad3 is now known as wm3|food
  1117. # [18:45] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  1118. # [18:45] * Joins: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6)
  1119. # [18:46] * Joins: boogyman (~boogy@unaffiliated/boogyman)
  1120. # [18:53] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 245 seconds)
  1121. # [18:55] * Joins: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  1122. # [18:58] * Quits: baba (~sallabanc@69.50.70.12) (Ping timeout: 260 seconds)
  1123. # [18:59] * Joins: dave_levin (~dave_levi@nat/google/x-wcfnteillvnpmsur)
  1124. # [19:01] * Joins: weinig_ (~weinig@17.246.19.141)
  1125. # [19:05] * Quits: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36) (Ping timeout: 276 seconds)
  1126. # [19:05] * weinig_ is now known as weinig
  1127. # [19:07] * Joins: othermaciej (~mjs@17.246.16.89)
  1128. # [19:09] * Joins: sicking (~chatzilla@nat/mozilla/x-nsbrgivqfgbzofev)
  1129. # [19:09] * Joins: ap_ (~ap@17.246.17.28)
  1130. # [19:10] * Joins: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
  1131. # [19:13] * Quits: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6) (Ping timeout: 276 seconds)
  1132. # [19:13] * ap_ is now known as ap
  1133. # [19:15] * Joins: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net)
  1134. # [19:26] * Joins: aho (~nya@fuld-4d00d439.pool.mediaWays.net)
  1135. # [19:30] <gsnedders> Yay for WebKit behavioural changes linked to Radar issues!
  1136. # [19:33] * Quits: tndH (~Rob@86.10.208.3) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
  1137. # [19:37] * Quits: mat_t (~mattomasz@91.189.88.12) (Quit: This computer has gone to sleep)
  1138. # [19:39] * Joins: tndH (~Rob@86.10.208.3)
  1139. # [19:42] * Joins: apucacao (~apucacao@S010600226b6dbc54.vc.shawcable.net)
  1140. # [19:43] * Quits: BlurstOfTimes (~blurstoft@168.203.117.112) (Remote host closed the connection)
  1141. # [19:43] <JonathanNeal> Unless I missed it @ http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#annotations-for-assistive-technology-products-(aria) the paragraph element <p> doesn't have an implicit aria role?
  1142. # [19:44] * Quits: weinig (~weinig@17.246.19.141) (Remote host closed the connection)
  1143. # [19:45] * Joins: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36)
  1144. # [19:47] * Joins: karlushi (~karlushi@fw.vdl2.ca)
  1145. # [19:55] * abarth|zZz is now known as abarth
  1146. # [19:59] * Quits: payman_s (~payman@77.72.99.119) (Quit: Leaving)
  1147. # [20:02] * Quits: phrearch (~phrearch_@82-136-229-19.ip.telfort.nl) (Quit: Leaving)
  1148. # [20:03] * Joins: maikmerten_ (~maikmerte@port-92-201-254-64.dynamic.qsc.de)
  1149. # [20:05] * Quits: maikmerten (~maikmerte@port-92-201-94-144.dynamic.qsc.de) (Ping timeout: 265 seconds)
  1150. # [20:14] * Quits: Peter- (~peter@5ED0FB51.cable.ziggo.nl) (Read error: Connection reset by peer)
  1151. # [20:16] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
  1152. # [20:18] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1153. # [20:22] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Quit: robb1e)
  1154. # [20:23] * Joins: Peter- (~peter@5ED0FB51.cable.ziggo.nl)
  1155. # [20:27] <AryehGregor> Does anyone here know about the File API spec? It seems to have no way to look at pieces of a large file without loading the whole thing into memory.
  1156. # [20:27] <AryehGregor> I'm trying to figure out if 1) this is true, and 2) it's been discussed before.
  1157. # [20:31] <AryehGregor> I guess I'll just post to public-webapps.
  1158. # [20:40] * Joins: robb1e (~robb1e@86.161.128.62)
  1159. # [20:48] * Quits: erlehmann (~erlehmann@dslb-188-102-048-076.pools.arcor-ip.net) (Quit: Ex-Chat)
  1160. # [20:51] * Joins: dbaron (~dbaron@nat/mozilla/x-dlyiiioipvfdxszj)
  1161. # [20:53] * Quits: kbrosnan (~kbrosnan@ip24-250-54-36.ri.ri.cox.net) (Quit: leaving)
  1162. # [20:54] * Quits: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp) (Ping timeout: 245 seconds)
  1163. # [20:54] * Quits: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com) (Ping timeout: 258 seconds)
  1164. # [20:57] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
  1165. # [21:08] <JonathanNeal> <nav> still need headings, yes?
  1166. # [21:08] <jgraham> Not "needs"
  1167. # [21:08] <jgraham> But it is a section it can have a heading
  1168. # [21:08] <jgraham> Otherwise a reasonable UA would make something up
  1169. # [21:10] * Joins: boaz (~boaz@10.sub-75-193-78.myvzw.com)
  1170. # [21:10] * Joins: MikeSmith (~MikeSmith@EM114-48-139-187.pool.e-mobile.ne.jp)
  1171. # [21:11] * Quits: maikmerten_ (~maikmerte@port-92-201-254-64.dynamic.qsc.de) (Remote host closed the connection)
  1172. # [21:13] <JonathanNeal> So, it's safe to abandon a heading for a <nav>
  1173. # [21:13] <JonathanNeal> Is that written anywhere, though?
  1174. # [21:13] <AryehGregor> It's not written anywhere that you have to have a heading for a <nav>.
  1175. # [21:13] <boogyman> abandon? wtf
  1176. # [21:13] <AryehGregor> So, you can infer that you don't.
  1177. # [21:14] <boogyman> <nav> spec states that it's for some sort of page navigation, there's no reference to required pre-req encapsulation
  1178. # [21:15] <JonathanNeal> boogyman, well, the last time I asked about it, I seem to remember there being strong consensus to include it. So, I would be abandoning a previous paradigm I thought to follow.
  1179. # [21:16] * Quits: dustinbrewer (~dustinbre@99-17-42-25.lightspeed.okcbok.sbcglobal.net) (Ping timeout: 264 seconds)
  1180. # [21:16] <JonathanNeal> I just have to get over the fact that gsnedders gonna call my navigation an Untitled Section.
  1181. # [21:16] <gsnedders> JonathanNeal: Well, yeah
  1182. # [21:16] <gsnedders> I'm lazy :P
  1183. # [21:17] <gsnedders> (I was going to fix it, then I realized how much effort it would be.)
  1184. # [21:17] * Quits: plainhao (~plainhao@mail.xbiotica.com) (Quit: plainhao)
  1185. # [21:17] <boogyman> The nature of the <nav> implies it would be encapsulated by <header>, however it's not 'technically' wrong
  1186. # [21:17] <JonathanNeal> gsnedders, it is difficult to have it say something like "Navigation" if it comes from a nav?
  1187. # [21:17] * Quits: boaz (~boaz@10.sub-75-193-78.myvzw.com) (Ping timeout: 245 seconds)
  1188. # [21:18] * JonathanNeal activates gsnedders encouragement mode.
  1189. # [21:20] <gsnedders> JonathanNeal: Yes
  1190. # [21:22] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Ping timeout: 240 seconds)
  1191. # [21:23] * Joins: Ms2ger (~Ms2ger@91.181.0.66)
  1192. # [21:27] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
  1193. # [21:31] * Joins: kbrosnan (~kbrosnan@ip24-250-54-36.ri.ri.cox.net)
  1194. # [21:33] <AryehGregor> I see references to being able to slice a File into Blobs.
  1195. # [21:33] <AryehGregor> Am I just missing that somewhere?
  1196. # [21:35] * Joins: jamesr (~jamesr@nat/google/x-rmcdpefmypbsfcjc)
  1197. # [21:37] * Quits: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net) (Quit: zzzzz)
  1198. # [21:42] <AryehGregor> Bingo! http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice
  1199. # [21:51] * Quits: sicking (~chatzilla@nat/mozilla/x-nsbrgivqfgbzofev) (Read error: Operation timed out)
  1200. # [21:59] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  1201. # [22:01] <gsnedders> jgraham: I'm not sure it's possible to implement LysKOM as a Thunderbird extension
  1202. # [22:01] * Joins: zcorpan_ (~zcorpan@c-879ae355.410-6-64736c14.cust.bredbandsbolaget.se)
  1203. # [22:02] * Quits: cyphase (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net) (*.net *.split)
  1204. # [22:03] <gsnedders> "Conferences hold articles. They are represented in the protocol as a data type called Conference. Each conference has a creator, the person who created the conference, and a supervisor, a conference whose members can modify the conference. If the supervisor is a person, the members of that person's mailbox are supervisors, which in most cases is only that person."
  1205. # [22:03] <gsnedders> WTH?
  1206. # [22:05] <othermaciej> I hope most nouns in that paragraph are terms of art
  1207. # [22:05] <gsnedders> Are people conferences?
  1208. # [22:05] <gsnedders> Or how else can a supervisor be a conference and a person?
  1209. # [22:06] * Joins: cyphase (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net)
  1210. # [22:06] <Philip`> That sounds like a typo to me
  1211. # [22:06] <Philip`> (Should be "a person whose members")
  1212. # [22:06] <jgraham> Argh
  1213. # [22:07] <Philip`> Oh, maybe not
  1214. # [22:07] <gsnedders> (For the curiour, that's from the LysKOM spec)
  1215. # [22:07] <Philip`> because then "If the supervisor is a person" wouldn't make sense
  1216. # [22:07] <jgraham> I just lost an email
  1217. # [22:07] <gsnedders> The spec also contains, "Long live FORTRAN!".
  1218. # [22:07] <jgraham> Stupid web browser
  1219. # [22:07] * Joins: aliok (55672cf2@gateway/web/freenode/ip.85.103.44.242)
  1220. # [22:07] * Philip` decides to happily not understand it
  1221. # [22:08] <jgraham> gsnedders: This is #whatwg we don't talk about legacy internet technologies that should have died years ago but mysteriously linger on here
  1222. # [22:08] <jgraham> Oh wait...
  1223. # [22:09] * Joins: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
  1224. # [22:09] <aliok> HI all, can anyone point me to some document where I can learn styling Html5 date picker?
  1225. # [22:09] * Quits: davidb_ (~davidb@mozca02.ca.mozilla.com) (Quit: davidb_)
  1226. # [22:09] <jgraham> gsnedders: (FWIW I assume that the underlying model is that "everything's a conference")
  1227. # [22:10] <jgraham> (but I could be wrong)
  1228. # [22:10] <gsnedders> jgraham: This isn't mentioned in the spec
  1229. # [22:10] <jgraham> gsnedders: What isn't?
  1230. # [22:10] <gsnedders> And it's implied People are a separate type to Conference and Text-Stat
  1231. # [22:11] <zcorpan_> micheil: array won't throw. it'll just be converted to a string
  1232. # [22:11] * Quits: foolip (~foolip@83.218.67.122) (Ping timeout: 265 seconds)
  1233. # [22:12] <jgraham> gsnedders: From reading the above I would assume that People are a subtype of Conference
  1234. # [22:12] <AryehGregor> aliok, you can't, basically.
  1235. # [22:12] <jgraham> But what do I know
  1236. # [22:12] <AryehGregor> Not yet, anyway.
  1237. # [22:12] * Quits: zcorpan_ (~zcorpan@c-879ae355.410-6-64736c14.cust.bredbandsbolaget.se) (Remote host closed the connection)
  1238. # [22:12] <gsnedders> jgraham: I'd assume that if it weren't for the next section in the spec
  1239. # [22:13] <aliok> AryehGregor, thanks anyway.
  1240. # [22:14] <jgraham> gsnedders: Oh
  1241. # [22:14] <aliok> BTW, if anyone interested we're implementing Html5 enabled JSF components. A live demo is deployed at http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf
  1242. # [22:14] <jgraham> gsnedders: (I don't see why what you said precludes the thunderbird extension, although I am not sure how one would implement "mark all messages with the same id as read")
  1243. # [22:14] <jgraham> (maybe the feed support already does that?)
  1244. # [22:15] <gsnedders> jgraham: I don't see how you can implement a new incoming and outcoming protocol in an extension
  1245. # [22:15] <gsnedders> But maybe the docs are just bad
  1246. # [22:16] * Quits: boogyman (~boogy@unaffiliated/boogyman) (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])
  1247. # [22:17] * Joins: BlurstOfTimes (~blurstoft@168.203.117.112)
  1248. # [22:20] <jgraham> gsnedders: jcranmer had some blog posts
  1249. # [22:20] <jgraham> They didn't implement a new protocol I guess
  1250. # [22:24] <aliok> AryehGregor, styling of those is written somehere in some spec but not implemented yet, right?
  1251. # [22:31] <jgraham> abarth, hsivonen: Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10221 on the text node coalescing behaviour
  1252. # [22:33] * Joins: kennyluck_ (~kennyluck@EM111-188-31-21.pool.e-mobile.ne.jp)
  1253. # [22:36] * Quits: kennyluck (~kennyluck@EM114-48-72-43.pool.e-mobile.ne.jp) (Ping timeout: 245 seconds)
  1254. # [22:36] * kennyluck_ is now known as kennyluck
  1255. # [22:40] * Joins: meandi (~meandi@dynadsl-080-228-69-213.ewetel.net)
  1256. # [22:42] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
  1257. # [22:47] * Quits: robb1e (~robb1e@86.161.128.62) (Ping timeout: 245 seconds)
  1258. # [22:52] <jamesr> Philip`: is there any way to get the output from your canvas conformance suite in a more machine-parsable way? i want to compare the output of http://philip.html5.org/tests/canvas/suite/tests/index.2d.html between two different builds and i can't see any way to do that other than looking at all the squares
  1259. # [22:52] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
  1260. # [22:55] <Philip`> jamesr: If you use http://philip.html5.org/tests/canvas/suite/reportgenentry.html then it'll generate YAML code in the textarea at the bottom
  1261. # [22:55] <Philip`> The submit button won't work so don't click that
  1262. # [22:55] <Philip`> but it should be possible to diff the outputs
  1263. # [22:56] <jamesr> ok
  1264. # [22:56] <jamesr> why YAML?
  1265. # [22:56] <Philip`> Why not?
  1266. # [22:57] <Philip`> It's easy to generate and easy to read and easy to parse (given suitable libraries)
  1267. # [22:57] * Quits: BlurstOfTimes (~blurstoft@168.203.117.112) (Remote host closed the connection)
  1268. # [22:57] <jamesr> but <insert markup system here> is clearly superior!
  1269. # [22:57] <jamesr> Philip`: thanks, i think that'll do the trick
  1270. # [22:57] <Philip`> and I was already using it for writing the test cases since it's concise and human-writable
  1271. # [22:58] <Philip`> and it's complex and crazy enough to be fun
  1272. # [22:58] * Joins: FireFly (~firefly@unaffiliated/firefly)
  1273. # [22:59] * Quits: meandi (~meandi@dynadsl-080-228-69-213.ewetel.net) (Ping timeout: 245 seconds)
  1274. # [22:59] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
  1275. # [23:03] <jcranmer> gsnedders: with a bit of pain
  1276. # [23:03] <gsnedders> jcranmer: So a bit of pain there, and a lot of pain at the badly documented protocol? Nice.
  1277. # [23:03] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
  1278. # [23:04] <jcranmer> if you're doing a wire protocol, you're likely using C++ already, which is easier
  1279. # [23:04] <jcranmer> it basically lacks documentation on the receiving end
  1280. # [23:04] <gsnedders> s/$/ if you know C++/
  1281. # [23:04] <jcranmer> binary protocol stuff in JS is not fun
  1282. # [23:04] <gsnedders> I wasn't really thinking about using JS
  1283. # [23:05] <gsnedders> JS doesn't work that well for binary data
  1284. # [23:05] <jcranmer> for TB, you pretty much have a choice of JS or C++
  1285. # [23:06] <gsnedders> I know.
  1286. # [23:06] <gsnedders> I, uh, wasn't entirely convinced I wanted to implement it in TB anyway
  1287. # [23:06] <jcranmer> fortunately, it should become easier in the future
  1288. # [23:06] <gsnedders> jgraham is the once convinced of that.
  1289. # [23:06] <gsnedders> :)
  1290. # [23:06] <gsnedders> (I think a more radical UI would be better, but oh well)
  1291. # [23:07] * Joins: baba (~sallabanc@69.50.70.12)
  1292. # [23:09] <AryehGregor> aliok, I don't know if a spec even exists at this point.
  1293. # [23:09] * Quits: ROBOd (~robod@89.123.178.63) (Quit: .)
  1294. # [23:10] * Joins: kangax_ (~kangax@208.82.12.210)
  1295. # [23:16] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1296. # [23:16] * Joins: sicking (~chatzilla@nat/mozilla/x-vwxhzdltbnzahkpr)
  1297. # [23:19] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Quit: robb1e)
  1298. # [23:22] * Quits: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  1299. # [23:38] * Joins: eric_carlson (~ericc@2620:0:1b00:1191:223:32ff:feb1:5d30)
  1300. # [23:38] * Joins: weinig_ (~weinig@17.246.19.141)
  1301. # [23:39] * Quits: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36) (Read error: Operation timed out)
  1302. # [23:39] * weinig_ is now known as weinig
  1303. # [23:40] * Quits: franksalim (~frank@adsl-75-61-93-123.dsl.pltn13.sbcglobal.net) (Ping timeout: 276 seconds)
  1304. # [23:47] * Quits: smaug___ (~chatzilla@cs181150024.pp.htv.fi) (Quit: ChatZilla 0.9.86 [Firefox 4.0b2pre/20100719125338])
  1305. # [23:54] * Joins: ZdenekKostal (~kostal_zd@zakaznici.it-help.cz)
  1306. # [23:58] * Parts: ZdenekKostal (~kostal_zd@zakaznici.it-help.cz)
  1307. # [23:59] * Quits: eric_carlson (~ericc@2620:0:1b00:1191:223:32ff:feb1:5d30) (Quit: eric_carlson)
  1308. # [23:59] * Joins: franksalim (~frank@adsl-75-61-93-123.dsl.pltn13.sbcglobal.net)
  1309. # Session Close: Thu Jul 22 00:00:00 2010

The end :)