/irc-logs / freenode / #whatwg / 2011-05-24 / end

Options:

  1. # Session Start: Tue May 24 00:00:00 2011
  2. # Session Ident: #whatwg
  3. # [00:00] <AryehGregor> Interesting corner case. I'd like to say it's the same as hitting Enter in all cases, which suggests two.
  4. # [00:01] <TabAtkins> Argh, Chrome's formatting of SVG-in-<img> is SO BROKEN.
  5. # [00:01] <zcorpan> AryehGregor: agree it would make sense
  6. # [00:01] <AryehGregor> TabAtkins, so standardize it!
  7. # [00:01] <TabAtkins> AryehGregor: It is. We're just broken.
  8. # [00:01] <AryehGregor> Where is it standardized?
  9. # [00:02] <TabAtkins> The Image Values spec.
  10. # [00:03] <zcorpan> it's a DRAFT
  11. # [00:03] <zcorpan> it's NON-NORMATIVE
  12. # [00:03] <TabAtkins> omg
  13. # [00:03] <TabAtkins> YOU'RE RIGHT
  14. # [00:03] <zcorpan> it's NOT A STANDARD
  15. # [00:04] <smaug____> what is a standard nowadays ;)
  16. # [00:04] <zcorpan> html 4.01 and css 2.0
  17. # [00:04] <AryehGregor> Image Values as in CSS Image Values, or some other Image Values?
  18. # [00:04] * Quits: MrOpposite (~mropposit@unaffiliated/mropposite) (Quit: OMG, YOU KILLED OPPO!)
  19. # [00:04] <TabAtkins> The former.
  20. # [00:05] <TabAtkins> Theoretically, <img>s handle sizing concerns with the same mechanisms that background images use.
  21. # [00:05] <zcorpan> (some peeps at sitepoint forums actually argue along those lines)
  22. # [00:06] * Quits: tbassetto (~tbassetto@vau75-7-82-234-249-198.fbx.proxad.net) (Quit: tbassetto)
  23. # [00:06] <abarth> TabAtkins: SVG-in-IMG is a disaster
  24. # [00:06] <abarth> TabAtkins: blame eseidel
  25. # [00:06] <TabAtkins> abarth: I WILL
  26. # [00:06] <abarth> it's a giant hack and should be deleted, IMHO
  27. # [00:06] <TabAtkins> I'm going to have to make a PNG of this SVG now just so I don't have retarded sizing issues.
  28. # [00:06] <abarth> why not just use SVG-in-HTML ?
  29. # [00:07] <abarth> it makes infinitely more sense
  30. # [00:07] <TabAtkins> Because that won't validate as HTML4, which CSS specs are required to be. >_<
  31. # [00:07] <AryehGregor> Oh, you're only worried about sizing?
  32. # [00:07] <abarth> sounds like a bug in the CSS specs
  33. # [00:07] <TabAtkins> Well, it's a bug in w3c process.
  34. # [00:07] <AryehGregor> I thought you were talking about more important stuff, like how dynamic content is treated.
  35. # [00:07] <abarth> TabAtkins: use XHTML :)
  36. # [00:07] <TabAtkins> AryehGregor: Yes. SVG images without explicit viewport sizes are automatically treated as if their viewport was the size of the screen.
  37. # [00:08] <zcorpan> TabAtkins: if you would have just followed the STANDARDS then you wouldn't be having these issues
  38. # [00:08] <TabAtkins> Rather than the size of the <img>, as would make some kind of sense.
  39. # [00:08] <AryehGregor> TabAtkins, why don't you give an explicit viewport size?
  40. # [00:08] <TabAtkins> AryehGregor: Because I gave it a viewBox, which *should* be enough, and I'm angry at it.
  41. # [00:10] <TabAtkins> But anyway, I've now given it an explicit width and height instead, grr.
  42. # [00:13] * Quits: Smylers (~smylers@host109-157-249-110.range109-157.btcentralplus.com) (Quit: Leaving.)
  43. # [00:24] * Quits: Jon47 (~jon47@204.56.125.50) (Quit: Leaving.)
  44. # [00:31] * Quits: jdaggett (~jdaggett@y227145.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
  45. # [00:33] * Quits: zcorpan (~zcorpan@c-8798e355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
  46. # [00:40] * Quits: othermaciej (~mjs@17.246.16.178) (Remote host closed the connection)
  47. # [00:41] * Joins: erlehmann (~erlehmann@89.204.153.67)
  48. # [00:41] * Joins: othermaciej (~mjs@2620:149:4:401:8ab:3727:472:e19d)
  49. # [00:43] * Quits: ifette (~ifette@nat/google/x-wtdyrarnituntinu) (Quit: ifette)
  50. # [00:49] * Joins: kangax (40140afc@gateway/web/freenode/ip.64.20.10.252)
  51. # [00:52] <kangax> Can someone clarify canvas' "destination-atop" globalCompositeOperation? Chrome and FF disagree (based on spec, it seems like Chrome is right).
  52. # [00:53] <kangax> test: http://kangax.github.com/jstests/canvas_globalcompositeoperation_test/ — choosing destination-atop and oval.png "clips" destination content in Chrome, but not in FF. Which one is right?
  53. # [00:55] <roc> FF
  54. # [00:55] <roc> try it in IE9
  55. # [00:55] <roc> or opera
  56. # [00:55] <kangax> i did
  57. # [00:55] <kangax> all non-webkit's seem to agree
  58. # [00:56] <roc> yes, it's a Webkit bug
  59. # [00:56] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  60. # [00:57] <roc> they clip the effect of the operator to the shape of the source object, or something like that
  61. # [00:57] <roc> the spec says not to do that
  62. # [00:57] <TabAtkins> Yeah, that's basically it. For some defintion of "the shape".
  63. # [00:57] <kangax> webkit's behavior looks more useful for my use case
  64. # [00:57] <roc> kangax: maybe so, but you can probably clip to the shape yourself easily enough
  65. # [00:57] <Philip`> Is your use case unable to use clip()?
  66. # [00:57] <kangax> i basically want to clip all the content to my (masking) image
  67. # [00:57] <roc> I don't think Webkit's behavior is bad, but no-one could ever figure out how to spec it right
  68. # [00:57] <erlehmann> kangax, does this help? https://developer.mozilla.org/en/Canvas_tutorial/Compositing
  69. # [00:58] <kangax> that's the thing — clip operates on current path, from what i understand, but I'd like to use an image (which doesn't affect it)
  70. # [00:58] <roc> just clip to the rectangle of the image
  71. # [00:59] <kangax> let's say i have an image of a flower — just a contour really — and i want to clip all the content to it. I don't have vector representation of an image. How to do it?
  72. # [01:00] <roc> the Webkit bug doesn't help you there does it? My understanding is that the "shape" it clips to would be the image rectangle in that case
  73. # [01:01] * Quits: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net) (Quit: linclark)
  74. # [01:01] <kangax> ah yes, that's the thing
  75. # [01:01] <kangax> clipping to non-rectangular shape is what's useful
  76. # [01:01] * Quits: othermaciej (~mjs@2620:149:4:401:8ab:3727:472:e19d) (Quit: othermaciej)
  77. # [01:01] <TabAtkins> The SVG compositing spec has a switch for the two behaviors.
  78. # [01:01] <TabAtkins> Of course, SVG has a good definition of the "shape" of an object. ^_^
  79. # [01:01] <kangax> in which case I'd be able to create an image with transparent bg
  80. # [01:02] <kangax> ..and clip everything to that image
  81. # [01:03] <kangax> TabAtkins: perhaps introducing another compositing mode would make sense then? i would think my usecase is not that uncommon
  82. # [01:03] <Philip`> The spec composites the image as if it were infinitely large and surrounded by transparency, so if you want everything outside the image to be clipped out then you should make the image contain transparency for clipped-out regions
  83. # [01:04] <Philip`> and then probably render with destination-in so it shows the original canvas content where the image is solid, and shows transparency elsewhere
  84. # [01:04] <Philip`> if that's roughly what you want
  85. # [01:04] * Quits: stefan-_ (~music@hiwi0.wi2.uni-trier.de) (Remote host closed the connection)
  86. # [01:04] <kangax> Philip`: but my overlaying (source) image is exactly like this — has content in the middle and transparency surrounding it
  87. # [01:05] <kangax> i though this opaque content in the middle will serve as clipping mask
  88. # [01:05] <kangax> *thought
  89. # [01:05] <Philip`> Can't you just use destination-in (I think), then?
  90. # [01:06] <kangax> that doesn't work in either Chrome nor FF
  91. # [01:07] <kangax> ..neither in Opera (just checked — all of them result in white nothingness)
  92. # [01:08] * Quits: dbaron (~dbaron@nat/mozilla/x-zrtfvyqbxnzqodet) (Ping timeout: 246 seconds)
  93. # [01:09] <jwalden> anyone: what browsers implement the standardized gradient syntax? gecko and ie alone? or am I missing someone?
  94. # [01:10] <gsnedders> jwalden: The CSS3 stuff?
  95. # [01:10] <gsnedders> jwalden: I believe we do.
  96. # [01:10] <TabAtkins> gecko implements a slightly older version of the syntax. webkit implements the new syntax, though with some bugs. opera and ie now implement the new syntax.
  97. # [01:12] * Joins: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net)
  98. # [01:16] <kangax> so... "shape" of a compositing object (in this case — an image) is what's underspecified at the moment?
  99. # [01:16] <TabAtkins> Yeah.
  100. # [01:17] <TabAtkins> If shape were properly defined, the compositing behavior is trivial.
  101. # [01:17] <kangax> should i bring it to the mailing list?
  102. # [01:17] <TabAtkins> Go ahead, though I think it's been discussed before.
  103. # [01:17] <kangax> ok, i'll check out archives
  104. # [01:18] <kangax> although... if the definition was to be specified, how will whatwg decide which one to pick? :)
  105. # [01:18] <kangax> introducing new mode would help of course
  106. # [01:20] <TabAtkins> Just add a switch, and default to the majority (global, not shape-constrained).
  107. # [01:20] <jamesr> webkit is switching to the canvas specified model for canvas 2d shortly, btw
  108. # [01:20] <kangax> oh boy
  109. # [01:21] <jamesr> meaning destination-in will clear every pixel that is fully transparent in the thingy being drawn
  110. # [01:21] <jamesr> you can get the behavior you want most of the time by setting an explicit clip
  111. # [01:21] * Joins: homata_ (~homata_@58x158x182x50.ap58.ftth.ucom.ne.jp)
  112. # [01:21] <kangax> jamesr: explicit clip as in `clip()`?
  113. # [01:21] <jamesr> yeah
  114. # [01:22] <kangax> jamesr: that means you're confined to a set of low-level commands for creating your clipping path :)
  115. # [01:22] <kangax> instead of just drawing an image
  116. # [01:22] <jamesr> well, images have rectangular clipping regions normally
  117. # [01:22] * Joins: dbaron (~dbaron@nat/mozilla/x-dagserzqblzcouau)
  118. # [01:23] <jamesr> so it's pretty easy to construct a clip around the image or whatever portion you want the composite operation to apply in
  119. # [01:23] <jamesr> you can also expect that most values for globalCompositeOperation other than the default are buggy in current browsers
  120. # [01:23] <kangax> oh i know
  121. # [01:24] <jamesr> but if you want to draw an image then normally you want to construct a rectangle around the image and clip() before drawing, if you only want to apply the composite operation inside the bounds of the image
  122. # [01:24] <kangax> i won't be using this behavior in any case... due to such poor "support" of it, but wanted to get to the bottom of it
  123. # [01:24] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 258 seconds)
  124. # [01:25] <kangax> jamesr: i don't think that would help me, since clipping region would still be rectangular (just a bounding box of an image)
  125. # [01:26] <kangax> jamesr: if i'm understanding you correctly
  126. # [01:26] <jamesr> what clipping region do you want?
  127. # [01:26] <kangax> jamesr: non-rectangular of course
  128. # [01:26] <jamesr> oh you want to use the opacity in the image?
  129. # [01:26] <kangax> yep
  130. # [01:26] <jamesr> it don't do that :)
  131. # [01:27] <kangax> webkit does :)
  132. # [01:27] <jamesr> well, only by accident
  133. # [01:27] <jamesr> it's not consistent if you use, say, gradients or patterns
  134. # [01:27] <kangax> i undestand
  135. # [01:28] <kangax> well, TabAtkins says SVG has behavior similar to what I want and it seems like a pretty common use case — just clipping something to a non-rectangular, non-vector shape (image with transparent content being perfect candidate)
  136. # [01:29] <TabAtkins> Clipping to a shape and clipping to the non-transparent regions are a bit different.
  137. # [01:29] <jamesr> you can clip to a shape in canvas
  138. # [01:29] <jamesr> but there's no notion of clipping to opacity
  139. # [01:29] <kangax> jamesr: yeah, only vector one
  140. # [01:29] <TabAtkins> You can do a <circle fill="transparent" ... /> in SVG, which will apply the compositing op to the circle even though it's transparent.
  141. # [01:29] <Philip`> Use getImageData, create a path by tracing around every non-transparent pixel, call clip() - easy :-)
  142. # [01:30] <kangax> maybe i should just do this manually
  143. # [01:30] <kangax> Philip`: was just thinking that :)
  144. # [01:30] <kangax> can only imagine the resulting performance of something like this
  145. # [01:32] <kangax> i can also probably find all transparent pixels of masking image and then "transparentize" those same pixels on canvas
  146. # [01:33] * Quits: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net) (Quit: linclark)
  147. # [01:34] * Philip` would have thought there must be an easier way to do this by drawing the image onto a large temporary canvas and then drawing that back onto the main canvas with appropriate compositing mode, to stop it depending on the inconsistent behaviour of compositing outside the source shape
  148. # [01:37] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  149. # [01:38] * Quits: jwalden (~waldo@2620:101:8003:200:222:68ff:fe15:af5c) (Quit: back shortly)
  150. # [01:40] * Quits: wolfman2000 (~wolfman20@152-20-182-126.rev.uncw.edu) (Remote host closed the connection)
  151. # [01:40] * Joins: Amorphous (jan@unaffiliated/amorphous)
  152. # [01:42] <kangax> Philip`: it's not even that — FF considers image shape to be that of a box, not its opaque content
  153. # [01:43] * Joins: miketaylr (~miketaylr@user-160vrg5.cable.mindspring.com)
  154. # [01:45] * Hixie mumbles something abouyt 100+ post threads that have 100+ proposals and no use case descriptions
  155. # [01:46] * Quits: hij1nx (~hij1nx@207.239.107.3) (Quit: hij1nx)
  156. # [01:48] * Joins: rkp (handcraft@cpc2-cmbg14-2-0-cust484.5-4.cable.virginmedia.com)
  157. # [01:49] * Parts: rkp (handcraft@cpc2-cmbg14-2-0-cust484.5-4.cable.virginmedia.com)
  158. # [01:52] * Joins: bacilla (handcraft@cpc2-cmbg14-2-0-cust484.5-4.cable.virginmedia.com)
  159. # [01:53] * Joins: othermaciej (~mjs@2620:149:4:401:dc7d:87b3:3587:bad7)
  160. # [01:54] * Quits: smaug____ (~chatzilla@78.41.210.66) (Ping timeout: 260 seconds)
  161. # [01:55] * Quits: bacilla (handcraft@cpc2-cmbg14-2-0-cust484.5-4.cable.virginmedia.com)
  162. # [01:55] * Joins: bacilla (handcraft@cpc2-cmbg14-2-0-cust484.5-4.cable.virginmedia.com)
  163. # [01:57] * Quits: jamesr (~jamesr@nat/google/x-kmjvlrryqjxvrjye) (Remote host closed the connection)
  164. # [02:03] * Quits: tndH (~Rob@cpc11-seac19-2-0-cust116.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.86.1-rdmsoft [XULRunner 1.9.0.1/2008072406])
  165. # [02:05] * Quits: boaz (~boaz@75-150-66-249-NewEngland.hfc.comcastbusiness.net) (Quit: boaz)
  166. # [02:05] * Quits: ojan (~ojan@nat/google/x-eptufhugqbzptxxe) (Quit: ojan)
  167. # [02:07] <jamesr_> Philip`, what happens in the canvas 2d spec if you set the transform to something non-invertible, set the globalCompositeOperation, then do a draw?
  168. # [02:07] * Joins: othermaciej_ (~mjs@17.203.15.180)
  169. # [02:11] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
  170. # [02:12] <jamesr_> it seems like firefox ignores the draw made with a non-invertible transform
  171. # [02:12] <jamesr_> instead of clearing everything
  172. # [02:15] * Joins: jwalden (~waldo@c-71-202-165-226.hsd1.ca.comcast.net)
  173. # [02:19] * Joins: nessy (~Adium@74.125.56.18)
  174. # [02:20] <Philip`> jamesr_: The transform matrix only applies to the shape, before it's drawn onto the infinite transparent bitmap
  175. # [02:20] <jamesr_> so the shape should map to nothing, and then the infinite transparent bitmap is composited?
  176. # [02:21] <Philip`> The compositing is independent of transforms, so I believe so
  177. # [02:21] <jamesr_> http://software.hixie.ch/utilities/js/canvas/?c.clearRect%280%2C%200%2C%20640%2C%20480%29%3B%0Ac.save%28%29%3B%0Atry%20{%0A%20%20c.globalCompositeOperation%20%3D%20%22source-over%22%3B%0A%20%20c.fillStyle%3D%22red%22%3B%0A%20%20c.fillRect%280%2C%200%2C%20640%2C%20480%29%3B%0A%20%20c.fillStyle%20%3D%20%22blue%22%3B%0A%20%20c.fillRect%2820.5%2C%2020.5%2C%2050%2C%2050%29%3B%0A%20%20c.globalCompositeOperation%20%3D%20%22destination-in%22%3B%0A%
  178. # [02:21] <jamesr_> 20%20c.setTransform%280%2C%200%2C%200%2C%200.5%2C%200%2C%200%29%3B%0A%20%20c.fillStyle%20%3D%20%22red%22%3B%0A%20%20c.fillRect%2810.5%2C%2030.5%2C%2020%2C%2020%29%3B%0A}%20finally%20{%0A%20%20c.restore%28%29%3B%0A}%0A
  179. # [02:21] <jamesr_> firefox just ignores the draw
  180. # [02:21] <Philip`> and drawing the finite shape with e.g. scale(0,0) should presumably be about the same as drawing with scale(1e-300, 1e-300), i.e. vanishingly small
  181. # [02:22] <jamesr_> opera clears the whole world
  182. # [02:22] <jamesr_> k, seems like a firefox bug
  183. # [02:22] <jamesr_> webkit will soon clear everything
  184. # [02:23] <Philip`> My desk is still greatly cluttered, so unfortunately it doesn't clear the whole world :-(
  185. # [02:24] * Joins: ben_h (~ben@128.250.195.138)
  186. # [02:24] <Philip`> Sounds like clearing the canvas is the spec-compliant behaviour, though I think any consequences of degenerate transforms in the spec are pretty much accidental
  187. # [02:25] * Quits: chriseppstein (~chris@209.119.65.162) (Quit: chriseppstein)
  188. # [02:29] * Joins: wolfman2000 (~wolfman20@rrcs-70-63-208-211.midsouth.biz.rr.com)
  189. # [02:36] * Quits: mpilgrim_ (~pilgrim@rrcs-24-206-36-125.midsouth.biz.rr.com) (Ping timeout: 250 seconds)
  190. # [02:37] * Joins: seventh (seventh@31.6.61.242)
  191. # [02:38] * Quits: miketaylr (~miketaylr@user-160vrg5.cable.mindspring.com) (Quit: miketaylr)
  192. # [02:41] * Quits: kangax (40140afc@gateway/web/freenode/ip.64.20.10.252) (Quit: Page closed)
  193. # [02:41] * Quits: ap (~ap@2620:149:4:401:226:4aff:fe14:aad6) (Quit: ap)
  194. # [02:44] * Joins: jamesr (~jamesr@nat/google/x-wmyorekxewqtrefe)
  195. # [02:49] * Joins: oojacoboo (~jacob@96-32-175-233.dhcp.gwnt.ga.charter.com)
  196. # [02:49] <oojacoboo> anyone have any input on the spec in regards to min/max widths?
  197. # [02:50] <oojacoboo> I'm finding that both firefox and chrome treat min with a higher priority than max
  198. # [02:50] <oojacoboo> actually, flat out negating the fact that max even exists
  199. # [02:51] <oojacoboo> the situation in a table is where I have min-width and max-width both applied to a <td>
  200. # [02:51] <TabAtkins> You talking about CSS min-width/max-width?
  201. # [02:51] <oojacoboo> in this case the min is the ONLY thing that even matters
  202. # [02:51] <oojacoboo> the max isn't even acknowledged
  203. # [02:52] <TabAtkins> The application of min/max to table-* elements is kinda weird.
  204. # [02:52] <oojacoboo> yes, CSS as you state
  205. # [02:52] <oojacoboo> kinda?
  206. # [02:52] <oojacoboo> bit of an understatement there
  207. # [02:52] <oojacoboo> but the fact that gecko and webkit both treat this the same is double disturbing
  208. # [02:53] * Joins: agektmr (~Adium@220.109.219.245)
  209. # [02:53] <oojacoboo> I'm having an extremely hard time understanding how we can be working on things like css transitions when we can't even get something as simple as min-width/max-width finished and into the spec and implemented
  210. # [02:54] <oojacoboo> it's probably one of the more fundamental styles, especially in regards to table layouts
  211. # [02:54] <TabAtkins> Table layout is *completely* unspecified.
  212. # [02:54] <TabAtkins> The 2.1 spec offers a suggested layout algorithm, but it doesn't match any browser in the details.
  213. # [02:55] <oojacoboo> ugh!
  214. # [02:55] <jamesr> everybody thinks the thing they care about is obviously more important than everything else
  215. # [02:55] <oojacoboo> jamesr: very true
  216. # [02:56] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  217. # [02:56] <oojacoboo> but not being able to specify min and max widths for a table with lots of data causes unwanted wrapping results, making the data hard to read, etc
  218. # [02:57] <oojacoboo> but I hardly see how something like css transitions could take precedence over something as basic as width styling
  219. # [02:57] <jamesr> exactly
  220. # [02:57] <TabAtkins> Because table layout works well enough, and nobody wants to spend time figuring out how to specify it properly.
  221. # [02:57] <jamesr> even when this is pointed out people still insist the thing they care about is obviously more important than whatever else :)
  222. # [02:57] <TabAtkins> But transitions are sexy and cool.
  223. # [02:57] <oojacoboo> ...
  224. # [02:57] <oojacoboo> that's the problem
  225. # [02:58] <TabAtkins> It's only a problem if you think table layout doesn't work properly. Most people don't care. ^_^
  226. # [02:59] <oojacoboo> I just want to say fuck tables and the horse they rode in on altogether at this point
  227. # [02:59] <jamesr> you also seem to think that the people who work on transitions would be working on table layout if they weren't working on transitions. that is definitely not true
  228. # [02:59] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
  229. # [02:59] <oojacoboo> jamesr: another good point
  230. # [02:59] * bga_ is now known as bga_|away
  231. # [02:59] * Quits: bga_|away (~bga@ppp91-122-182-131.pppoe.avangarddsl.ru) (Read error: Connection reset by peer)
  232. # [03:00] <oojacoboo> but seriously though, how hard is it to code up a min/max range...
  233. # [03:01] <TabAtkins> Obeying all the other implicit constraints that make up the big ball of pain that is table layout?
  234. # [03:02] <oojacoboo> TabAtkins: why would they come into play if these are specified?
  235. # [03:02] <TabAtkins> Everything comes into play when you layout tables.
  236. # [03:03] <TabAtkins> Imagine, for example, two cells that have "min-width: 100px", and a cell in another row that spans both columns and has "max-width: 150px".
  237. # [03:03] <TabAtkins> Now imagine that, rather than fully overlapping, it only partially overlaps, so you either have to ignore the constraint or find some way to fit the non-overlapping part of the cell into 50px.
  238. # [03:03] <oojacoboo> good point there, I'd fall back on the max in that case
  239. # [03:04] * Joins: agektmr1 (~Adium@220.109.219.245)
  240. # [03:04] * Quits: agektmr1 (~Adium@220.109.219.245) (Client Quit)
  241. # [03:04] <TabAtkins> min-width is pretty easy, all in all. Given that table cells are BFCs, they already have implicit min-width constraints of the width of the longest word in their contents.
  242. # [03:05] <TabAtkins> Max, though, just plain hurts.
  243. # [03:05] <oojacoboo> if min-width is specified, it's the king
  244. # [03:05] <oojacoboo> and then it just does whatever it wants
  245. # [03:05] * _uf0 is now known as __uf0
  246. # [03:05] <TabAtkins> But you just said you'd honor max-width, ignoring the min-width on the other cells!
  247. # [03:05] <oojacoboo> I have multiple cells min-width: 70px
  248. # [03:06] <oojacoboo> they are spanning to 95px on their own beyond the boundaries of the table width!
  249. # [03:06] * Quits: agektmr (~Adium@220.109.219.245) (Ping timeout: 246 seconds)
  250. # [03:06] * Joins: agektmr1 (~Adium@220.109.219.245)
  251. # [03:06] <oojacoboo> wdith: 77px !important doesn't even fix it
  252. # [03:07] <oojacoboo> ...
  253. # [03:07] <oojacoboo> width*
  254. # [03:08] <oojacoboo> I see the issues you present, but how to you explain that ^^ behavior?
  255. # [03:08] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
  256. # [03:08] <oojacoboo> s/to/do
  257. # [03:08] <TabAtkins> I don't. Like I said, table layout is unspecified. ^_^
  258. # [03:08] <TabAtkins> Also, I'm out for the day.
  259. # [03:08] <oojacoboo> later
  260. # [03:10] * Joins: ryanseddon (~RSeddon@202.126.98.210)
  261. # [03:10] * Joins: chriseppstein (~chris@c-71-202-84-148.hsd1.ca.comcast.net)
  262. # [03:10] * Joins: nessy (~Adium@74.125.56.18)
  263. # [03:21] * Joins: agektmr (~Adium@220.109.219.245)
  264. # [03:21] * Quits: chriseppstein (~chris@c-71-202-84-148.hsd1.ca.comcast.net) (Quit: chriseppstein)
  265. # [03:25] * Joins: agektmr2 (~Adium@2401:fa00:4:1012:fa1e:dfff:fee6:d74e)
  266. # [03:25] * Quits: agektmr1 (~Adium@220.109.219.245) (Ping timeout: 252 seconds)
  267. # [03:25] * Quits: agektmr (~Adium@220.109.219.245) (Ping timeout: 246 seconds)
  268. # [03:26] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
  269. # [03:27] * Quits: dbaron (~dbaron@nat/mozilla/x-dagserzqblzcouau) (Ping timeout: 246 seconds)
  270. # [03:27] * Quits: agektmr2 (~Adium@2401:fa00:4:1012:fa1e:dfff:fee6:d74e) (Client Quit)
  271. # [03:28] * Quits: othermaciej_ (~mjs@17.203.15.180) (Ping timeout: 276 seconds)
  272. # [03:29] * Joins: dbaron (~dbaron@nat/mozilla/x-wingmwagojomxinw)
  273. # [03:35] * Quits: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Quit: tomasf)
  274. # [03:36] * Joins: mpilgrim_ (~pilgrim@rrcs-24-206-36-125.midsouth.biz.rr.com)
  275. # [03:37] * Quits: cying (~cying@173-13-176-101-sfba.hfc.comcastbusiness.net) (Quit: cying)
  276. # [03:37] * Quits: dbaron (~dbaron@nat/mozilla/x-wingmwagojomxinw) (Ping timeout: 260 seconds)
  277. # [03:38] * Joins: agektmr (~Adium@220.109.219.244)
  278. # [03:39] * Quits: agektmr (~Adium@220.109.219.244) (Client Quit)
  279. # [03:40] * Joins: agektmr (~Adium@220.109.219.244)
  280. # [03:45] * Joins: agektmr1 (~Adium@220.109.219.244)
  281. # [03:45] * Quits: agektmr (~Adium@220.109.219.244) (Read error: Connection reset by peer)
  282. # [03:47] * Joins: nessy (~Adium@74.125.56.18)
  283. # [03:49] * Joins: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net)
  284. # [04:05] * Quits: jamesr (~jamesr@nat/google/x-wmyorekxewqtrefe) (Quit: jamesr)
  285. # [04:06] * Quits: The_8472 (~stardive@azureus/The8472) (Ping timeout: 252 seconds)
  286. # [04:08] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
  287. # [04:09] * Joins: bentruyman (~bentruyma@24-148-24-69.c3-0.prs-ubr2.chi-prs.il.cable.rcn.com)
  288. # [04:12] * Joins: The_8472 (~stardive@azureus/The8472)
  289. # [04:15] * Joins: miketaylr (~miketaylr@user-160vrg5.cable.mindspring.com)
  290. # [04:17] * Joins: othermaciej_ (~mjs@66.109.104.225)
  291. # [04:17] * Joins: boogyman (~boogy@unaffiliated/boogyman)
  292. # [04:19] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Quit: Now time for the weather. Tiffany?)
  293. # [04:21] * Quits: mpilgrim_ (~pilgrim@rrcs-24-206-36-125.midsouth.biz.rr.com) (Ping timeout: 250 seconds)
  294. # [04:23] * Joins: cgcardona (~cgcardona@unaffiliated/cgcardona)
  295. # [04:23] <cgcardona> thought I'd show this around in here in case anyone has any tips. https://audiofile.cc/
  296. # [04:24] * Joins: sephr_ (~Eli@c-98-235-63-240.hsd1.pa.comcast.net)
  297. # [04:27] * Quits: boogyman (~boogy@unaffiliated/boogyman) (Quit: ChatZilla 0.9.86.1 [Firefox 4.0.1/20110413222027])
  298. # [04:27] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  299. # [04:27] * Quits: sephr (~Eli@c-98-235-63-240.hsd1.pa.comcast.net) (Ping timeout: 246 seconds)
  300. # [04:35] * Quits: aho (~nya@fuld-590c76ac.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
  301. # [04:45] <erlehmann> cgcardona, LOL INTERNET. have you read the lilypond paper on why music is not really something representable with XML?
  302. # [04:45] <erlehmann> also, can you show me a demo? i cannot seem to find one.
  303. # [04:45] * Joins: nessy (~Adium@74.125.56.18)
  304. # [04:47] <cgcardona> erlehmann: no please post the link. The code you see at the top as well as the canvas are a live example
  305. # [04:47] <cgcardona> it's a new idea so thats the only example I have worth showing. After I get chords as well as sharps implemented i want to get some examples that change the notes with clicks and such
  306. # [04:50] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  307. # [04:52] <erlehmann> cgcardona, it might be this http://lilypond.org/doc/v2.12/Documentation/user/lilypond-learning/Background.html
  308. # [04:52] <erlehmann> the lilypond people may have stuff you might wish to use :)
  309. # [04:53] <cgcardona> i'll check it out. thanks
  310. # [04:53] * Joins: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net)
  311. # [04:54] * Joins: othermaciej__ (~mjs@66.109.104.225)
  312. # [04:54] * Quits: othermaciej_ (~mjs@66.109.104.225) (Read error: Connection reset by peer)
  313. # [04:55] * Joins: dbaron (~dbaron@nat/mozilla/x-degwyevhmfwozcgr)
  314. # [05:00] * Quits: dbaron (~dbaron@nat/mozilla/x-degwyevhmfwozcgr) (Client Quit)
  315. # [05:01] * Quits: othermaciej__ (~mjs@66.109.104.225) (Quit: othermaciej__)
  316. # [05:04] * Quits: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net) (Quit: cying)
  317. # [05:05] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  318. # [05:10] * Joins: chriseppstein (~chris@c-71-202-84-148.hsd1.ca.comcast.net)
  319. # [05:12] * Joins: othermaciej_ (~mjs@c-24-6-209-6.hsd1.ca.comcast.net)
  320. # [05:19] * Quits: sephr_ (~Eli@c-98-235-63-240.hsd1.pa.comcast.net) (Ping timeout: 246 seconds)
  321. # [05:19] * Quits: miketaylr (~miketaylr@user-160vrg5.cable.mindspring.com) (Quit: miketaylr)
  322. # [05:23] * Joins: chriseppstein_ (~chris@c-71-202-84-148.hsd1.ca.comcast.net)
  323. # [05:27] * Quits: chriseppstein (~chris@c-71-202-84-148.hsd1.ca.comcast.net) (Ping timeout: 276 seconds)
  324. # [05:27] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  325. # [05:28] * Quits: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net) (Quit: linclark)
  326. # [05:29] * chriseppstein_ is now known as chriseppstein
  327. # [05:33] * Quits: chriseppstein (~chris@c-71-202-84-148.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
  328. # [05:33] * Quits: riven (~riven@pdpc/supporter/professional/riven) (Read error: Connection reset by peer)
  329. # [05:34] * Joins: riven (~riven@pdpc/supporter/professional/riven)
  330. # [05:43] * Joins: nonge__ (~nonge@p5082BB51.dip.t-dialin.net)
  331. # [05:45] * Quits: nonge_ (~nonge@p508291DA.dip.t-dialin.net) (Read error: Operation timed out)
  332. # [05:46] * Quits: ben_alman (~ben_alman@web126.webfaction.com) (Quit: wat)
  333. # [05:47] * Joins: ben_alman (~ben_alman@web126.webfaction.com)
  334. # [05:55] * Joins: dbaron (~dbaron@173-228-28-218.dsl.dynamic.sonic.net)
  335. # [05:56] * Joins: hij1nx (~hij1nx@cpe-66-65-124-111.nyc.res.rr.com)
  336. # [05:57] * Quits: jwalden (~waldo@c-71-202-165-226.hsd1.ca.comcast.net) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2.17/20110428205629])
  337. # [05:57] * Quits: bentruyman (~bentruyma@24-148-24-69.c3-0.prs-ubr2.chi-prs.il.cable.rcn.com) (Quit: bentruyman)
  338. # [06:09] * dglazkov is now known as dglazkov|away
  339. # [06:21] * Joins: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net)
  340. # [06:21] * Quits: jochen__ (~jochen@nat/google/x-xvlafnctgoabbugc) (Remote host closed the connection)
  341. # [06:22] * Joins: jochen__ (~jochen@nat/google/x-kxeimamaepfszzqv)
  342. # [06:22] * Quits: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1) (Ping timeout: 260 seconds)
  343. # [06:23] * Quits: bacilla (handcraft@cpc2-cmbg14-2-0-cust484.5-4.cable.virginmedia.com)
  344. # [06:24] * Quits: seventh (seventh@31.6.61.242) (Ping timeout: 240 seconds)
  345. # [06:37] * Quits: MikeSmith (~MikeSmith@58x157x21x205.ap58.ftth.ucom.ne.jp) (Quit: MikeSmith)
  346. # [06:40] * Joins: hdhoang (~hdhoang@hdhoang.broker.freenet6.net)
  347. # [06:49] * Joins: ezoe (~ezoe@61-205-125-8f1.kyt1.eonet.ne.jp)
  348. # [06:50] * Joins: chriseppstein (~chris@c-67-188-108-209.hsd1.ca.comcast.net)
  349. # [07:03] * Quits: agektmr1 (~Adium@220.109.219.244) (Quit: Leaving.)
  350. # [07:07] * Joins: agektmr (~Adium@220.109.219.244)
  351. # [07:10] * Quits: dbaron (~dbaron@173-228-28-218.dsl.dynamic.sonic.net) (Quit: g'night)
  352. # [07:14] * heycam is now known as heycam|away
  353. # [07:19] * Quits: virtuelv (~virtuelv_@20.74.9.46.customer.cdi.no) (Ping timeout: 255 seconds)
  354. # [07:27] * Joins: Akilo (~kristof@lit75-1-81-57-239-230.fbx.proxad.net)
  355. # [07:30] <Akilo> saluton amikoj
  356. # [07:35] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
  357. # [07:38] * Joins: agektmr (~Adium@220.109.219.244)
  358. # [07:41] * Joins: ry (~ry@static-71-183-64-28.nycmny.fios.verizon.net)
  359. # [07:44] * Joins: Ankheg (~Ankheg@fs91-201-3-30.dubna-net.ru)
  360. # [07:46] * Joins: maikmerten (~merten@ls5dhcp197.cs.uni-dortmund.de)
  361. # [07:47] * Quits: hij1nx (~hij1nx@cpe-66-65-124-111.nyc.res.rr.com) (Quit: hij1nx)
  362. # [07:57] * Joins: micheil (~micheil@124-171-8-197.dyn.iinet.net.au)
  363. # [07:57] * Quits: micheil (~micheil@124-171-8-197.dyn.iinet.net.au) (Client Quit)
  364. # [07:59] * Joins: FireFly (~firefly@unaffiliated/firefly)
  365. # [08:17] * Quits: roc (~chatzilla@203-97-204-82.dsl.clear.net.nz) (Ping timeout: 260 seconds)
  366. # [08:22] * Joins: Ms2ger (~Ms2ger@91.181.64.45)
  367. # [08:28] * Joins: sicking (~chatzilla@dsl2.iceoasis.com)
  368. # [08:35] * Joins: zcorpan (~zcorpan@c-8798e355.410-6-64736c14.cust.bredbandsbolaget.se)
  369. # [08:37] * Joins: rimantas (~rimliu@93.93.57.193)
  370. # [08:41] * Joins: Maurice (~ano@77.222.73.150)
  371. # [08:45] * Joins: smaug____ (~chatzilla@78.41.210.66)
  372. # [08:47] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
  373. # [08:49] * Quits: chriseppstein (~chris@c-67-188-108-209.hsd1.ca.comcast.net) (Quit: chriseppstein)
  374. # [09:01] * Joins: Martijnc (~Martijnc@d54C02C64.access.telenet.be)
  375. # [09:01] * Joins: matjas (~matjas@91.182.178.25)
  376. # [09:02] * Quits: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net) (Quit: cying)
  377. # [09:04] * Quits: ezoe (~ezoe@61-205-125-8f1.kyt1.eonet.ne.jp) (Ping timeout: 276 seconds)
  378. # [09:04] * Quits: AryehGregor (~Simetrica@mediawiki/simetrical) (Ping timeout: 248 seconds)
  379. # [09:09] * Joins: Smylers (~smylers@host109-157-249-110.range109-157.btcentralplus.com)
  380. # [09:15] * Joins: mpt (~mpt@canonical/mpt)
  381. # [09:15] * Quits: smaug____ (~chatzilla@78.41.210.66) (Ping timeout: 258 seconds)
  382. # [09:20] * Joins: AryehGregor (~Simetrica@mediawiki/simetrical)
  383. # [09:20] * Quits: cgcardona (~cgcardona@unaffiliated/cgcardona) (Quit: zzzzz)
  384. # [09:21] * zcorpan notes that only FOs were filed as bugs
  385. # [09:22] <zcorpan> if somebody had a different argument and voted No or Abstain, maybe repeat the argument in a bug?
  386. # [09:23] * Quits: sicking (~chatzilla@dsl2.iceoasis.com) (Ping timeout: 260 seconds)
  387. # [09:41] * Parts: ryanseddon (~RSeddon@202.126.98.210)
  388. # [09:42] * Quits: ben_h (~ben@128.250.195.138) (Quit: ben_h)
  389. # [09:47] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
  390. # [09:53] * Joins: tndH (~Rob@cpc11-seac19-2-0-cust116.7-2.cable.virginmedia.com)
  391. # [09:56] * Joins: ezoe (~ezoe@61-205-124-8f1.kyt1.eonet.ne.jp)
  392. # [09:59] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
  393. # [10:00] * Joins: Scorchin (u1242@gateway/web/irccloud.com/x-xrxkfnigzbkqivfy)
  394. # [10:03] * Joins: msucan (~robod@92.86.247.27)
  395. # [10:07] * Joins: smaug____ (~chatzilla@74.125.57.58)
  396. # [10:10] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  397. # [10:14] * Joins: chriseppstein (~chris@99-34-231-235.lightspeed.sntcca.sbcglobal.net)
  398. # [10:16] * Quits: Rik` (~Rik`@2a01:e34:ec0f:1570:daa2:5eff:fe97:85ed) (Ping timeout: 264 seconds)
  399. # [10:18] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  400. # [10:29] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
  401. # [10:32] * Joins: micheil (~micheil@124-171-8-197.dyn.iinet.net.au)
  402. # [10:32] * Quits: micheil (~micheil@124-171-8-197.dyn.iinet.net.au) (Client Quit)
  403. # [10:34] * Joins: tbassetto (~tbassetto@2a01:e35:2eec:80a0:f2b4:79ff:fe15:3589)
  404. # [10:35] * Joins: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au)
  405. # [10:37] * Quits: mpt (~mpt@canonical/mpt) (Read error: Operation timed out)
  406. # [10:39] * Quits: tbassetto (~tbassetto@2a01:e35:2eec:80a0:f2b4:79ff:fe15:3589) (Quit: tbassetto)
  407. # [10:42] <hsivonen> mysterious. The ICU-based check for max week of a year always seems to return 52
  408. # [10:43] <jgraham> zcorpan: No surprise there then
  409. # [10:45] * Joins: jeremyselier (~Jeremy@92.103.127.226)
  410. # [10:50] * Joins: ben_h (~ben@CPE-58-161-40-52.czqd1.win.bigpond.net.au)
  411. # [10:51] * Joins: FireFly (~firefly@unaffiliated/firefly)
  412. # [10:52] * Quits: chriseppstein (~chris@99-34-231-235.lightspeed.sntcca.sbcglobal.net) (Quit: chriseppstein)
  413. # [10:58] * Joins: richt (~richt@pat-tdc.opera.com)
  414. # [11:01] * Joins: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se)
  415. # [11:07] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  416. # [11:07] * Joins: richt_ (~richt@guest.opera.com)
  417. # [11:08] * Quits: ben_h (~ben@CPE-58-161-40-52.czqd1.win.bigpond.net.au) (Quit: ben_h)
  418. # [11:09] * Quits: richt (~richt@pat-tdc.opera.com) (Ping timeout: 248 seconds)
  419. # [11:34] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  420. # [11:41] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: This computer has gone to sleep)
  421. # [11:42] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  422. # [11:42] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
  423. # [11:50] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  424. # [11:52] * Quits: smaug____ (~chatzilla@74.125.57.58) (Ping timeout: 246 seconds)
  425. # [11:54] * Joins: smaug____ (~chatzilla@74.125.57.58)
  426. # [11:56] * Quits: maikmerten (~merten@ls5dhcp197.cs.uni-dortmund.de) (Remote host closed the connection)
  427. # [11:57] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  428. # [12:04] * Quits: richt_ (~richt@guest.opera.com) (Read error: No route to host)
  429. # [12:04] * Joins: richt (~richt@pat-tdc.opera.com)
  430. # [12:05] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: Leaving)
  431. # [12:06] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  432. # [12:06] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (Quit: Leaving)
  433. # [12:08] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
  434. # [12:09] <asmodai> hahah, that ihatexml.py in html5lib XD
  435. # [12:11] * Joins: agektmr (~Adium@58x158x185x154.ap58.ftth.ucom.ne.jp)
  436. # [12:12] * Joins: mpt (~mpt@91.189.88.12)
  437. # [12:13] * Quits: mpt (~mpt@91.189.88.12) (Changing host)
  438. # [12:13] * Joins: mpt (~mpt@canonical/mpt)
  439. # [12:17] <hsivonen> still no editing action in the rel registry
  440. # [12:18] <hsivonen> I wonder if that's going to change once MikeSmith redeploys the back end of validator.w3.org
  441. # [12:19] * Joins: bga_ (~bga@ppp91-122-182-131.pppoe.avangarddsl.ru)
  442. # [12:20] * Joins: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de)
  443. # [12:25] <gsnedders> asmodai: jgraham is the wittiest of men.
  444. # [12:25] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Remote host closed the connection)
  445. # [12:25] <asmodai> gsnedders: Given the contents of the file I think the name is aptly chosen.
  446. # [12:27] * Joins: Rik` (~Rik`@2a01:e34:ec0f:1570:daa2:5eff:fe97:85ed)
  447. # [12:28] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  448. # [12:33] <zcorpan> based on google search suggestions for "is <char>", a lot of people are searching for "is <person> gay"
  449. # [12:35] <jgraham> zcorpan: Wow
  450. # [12:35] <jgraham> f is the first letter where I didn't get at leats one suggest matching that pattern
  451. # [12:36] <jgraham> Although I did get "is fish meat"
  452. # [12:36] <jgraham> So I am a little concerened with the general intelligience of people using Google
  453. # [12:36] <zcorpan> where as "are <char>" seems to mostly end with "real" and "good for you"
  454. # [12:36] * Joins: nessy (~Adium@124-149-62-235.dyn.iinet.net.au)
  455. # [12:36] <zcorpan> jgraham: try "is g" :)
  456. # [12:39] <jgraham> Honestly the pattern is so widespreaed I suspect people gaming the results for giggles
  457. # [12:40] * Quits: ezoe (~ezoe@61-205-124-8f1.kyt1.eonet.ne.jp) (Ping timeout: 244 seconds)
  458. # [12:40] <zcorpan> or people are really interested in whether other people are gay
  459. # [12:41] <jgraham> I suppose that is possible
  460. # [12:42] <zcorpan> time to donate blood plasma
  461. # [12:46] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Remote host closed the connection)
  462. # [12:47] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
  463. # [12:48] * Quits: agektmr (~Adium@58x158x185x154.ap58.ftth.ucom.ne.jp) (Quit: Leaving.)
  464. # [12:53] * Joins: agektmr (~Adium@58x158x185x154.ap58.ftth.ucom.ne.jp)
  465. # [12:53] * Joins: maikmerten (~merten@ls5dhcp197.cs.uni-dortmund.de)
  466. # [12:55] * __uf0 is now known as uf0
  467. # [12:56] * Quits: hdhoang (~hdhoang@hdhoang.broker.freenet6.net) (Quit: Leaving.)
  468. # [12:56] * Quits: smaug____ (~chatzilla@74.125.57.58) (Ping timeout: 246 seconds)
  469. # [12:56] * Joins: ezoe (~ezoe@112-68-245-203f1.kyt1.eonet.ne.jp)
  470. # [12:59] * Joins: kennyluck (~kennyluck@114-43-120-37.dynamic.hinet.net)
  471. # [12:59] * Quits: kennyluck (~kennyluck@114-43-120-37.dynamic.hinet.net) (Client Quit)
  472. # [12:59] * Joins: hdhoang (~hdhoang@203.210.202.182)
  473. # [13:00] * Joins: kennyluck (~kennyluck@114-43-120-37.dynamic.hinet.net)
  474. # [13:00] * Joins: _bga (~bga@95-55-42-35.dynamic.avangarddsl.ru)
  475. # [13:02] * Quits: Rik` (~Rik`@2a01:e34:ec0f:1570:daa2:5eff:fe97:85ed) (Remote host closed the connection)
  476. # [13:03] * Quits: bga_ (~bga@ppp91-122-182-131.pppoe.avangarddsl.ru) (Ping timeout: 264 seconds)
  477. # [13:23] <hsivonen> hmm. Why does V.nu have unused floating point datatypes?
  478. # [13:25] <Philip`> Maybe because the spec used to have floats until they got changed to doubles?
  479. # [13:26] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Quit: Now time for the weather. Tiffany?)
  480. # [13:26] * Joins: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de)
  481. # [13:30] * Joins: Rik` (~Rik`@mozilla-paris-253-99.cnt.nerim.net)
  482. # [13:31] <hsivonen> has the spec changed back and forth as far as exponent allowability on input type=number goes?
  483. # [13:32] <hsivonen> I can't believe the validator has been wrong for 4 years with the correct code in the codebase as dead code
  484. # [13:32] * hsivonen can't be bothered to do full version control archeology research
  485. # [13:37] <hsivonen> I'm rather shocked by the state of float handling in the validator
  486. # [13:38] * Quits: agektmr (~Adium@58x158x185x154.ap58.ftth.ucom.ne.jp) (Quit: Leaving.)
  487. # [13:38] <hsivonen> it looks like I almost fixed this stuff in 2007 and then forgot to take all the remaining steps
  488. # [13:38] <hsivonen> it's also possible that Hixie has had something too crazy in the spec at a critical moment
  489. # [13:40] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
  490. # [13:41] * Quits: homata_ (~homata_@58x158x182x50.ap58.ftth.ucom.ne.jp) (Remote host closed the connection)
  491. # [13:45] * Joins: nessy1 (~Adium@58-6-47-56.dyn.iinet.net.au)
  492. # [13:47] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
  493. # [13:47] * Quits: nessy (~Adium@124-149-62-235.dyn.iinet.net.au) (Ping timeout: 246 seconds)
  494. # [13:48] * Joins: agektmr (~Adium@58x158x185x154.ap58.ftth.ucom.ne.jp)
  495. # [13:48] * Joins: myakura (~myakura@FL1-118-111-219-47.tky.mesh.ad.jp)
  496. # [13:49] * Joins: MikeSmith (~MikeSmith@EM1-112-84-217.pool.e-mobile.ne.jp)
  497. # [13:54] <hsivonen> seriously, it's 2011 and we still get stuff like this in a spec: http://www.w3.org/WAI/PF/aria/complete#valuetype_number
  498. # [13:58] <hsivonen> why does the PFWG ask me to state if I'm commenting on behalf of an organization and if the org is a W3C group, Member org or other?
  499. # [13:59] <Philip`> Isn't http://www.w3.org/WAI/PF/aria/complete#typemapping the more relevant definition of "number"?
  500. # [13:59] <gsnedders> hsivonen: Because a comment from some W3C member could turn into a vote against the spec at PR at the AC level?
  501. # [14:00] <gsnedders> hsivonen: What would you rather the abstract model defined a number to be?
  502. # [14:02] <Philip`> http://www.w3.org/WAI/PF/aria/complete#valuetype_number seems plausible as a definition of what XML Schema calls the value space, although then the problem is the value space can't be represented by the lexical representations listed in http://www.w3.org/WAI/PF/aria/complete#typemapping
  503. # [14:02] <Philip`> (since they only do finite decimal numbers, not all real numbers)
  504. # [14:02] * Quits: espadrine (~thaddee_t@acces1527.res.insa-lyon.fr) (Quit: espadrine)
  505. # [14:02] <Philip`> but that's being a bit picky
  506. # [14:04] * Joins: richt_ (~richt@guest.opera.com)
  507. # [14:04] <hsivonen> Filed http://www.w3.org/WAI/PF/comments/details?comment_id=357
  508. # [14:05] * Quits: richt_ (~richt@guest.opera.com) (Remote host closed the connection)
  509. # [14:05] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Ping timeout: 252 seconds)
  510. # [14:05] * Quits: Ms2ger (~Ms2ger@91.181.64.45) (Read error: Connection reset by peer)
  511. # [14:06] <gsnedders> hsivonen: I think that section just defines the abstract ARIA model, not specific to any syntax.
  512. # [14:06] <hsivonen> Philip`: OK. so the spec fails by not linking to that section
  513. # [14:06] <hsivonen> gsnedders: I see. I don't like this abstract stuff.
  514. # [14:06] * Quits: richt (~richt@pat-tdc.opera.com) (Ping timeout: 240 seconds)
  515. # [14:06] <Philip`> hsivonen: That subsubsection says "These are generic types for states and properties, but do not define specific representation. See State and Property Attribute Processing for details on how these values are expressed and handled in host languages."
  516. # [14:07] <Philip`> which links to http://www.w3.org/WAI/PF/aria/complete#state_property_processing which links to http://www.w3.org/WAI/PF/aria/complete#typemapping
  517. # [14:07] * Joins: richt (~richt@guest.opera.com)
  518. # [14:07] <hsivonen> Philip`: ok.
  519. # [14:07] <Philip`> (though it says it's non-normative)
  520. # [14:07] <hsivonen> well, evidently, this is a readability failure
  521. # [14:08] * Quits: myakura (~myakura@FL1-118-111-219-47.tky.mesh.ad.jp) (Read error: Connection reset by peer)
  522. # [14:08] * Joins: myakura (~myakura@FL1-118-111-219-47.tky.mesh.ad.jp)
  523. # [14:10] <gsnedders> hsivonen: Well, really, it's no worse from an abstraction POV than HTML5, which only clearly defines the element definitions as abstract in one or two easy to miss places
  524. # [14:13] * Joins: smaug____ (~chatzilla@74.125.57.58)
  525. # [14:13] <Philip`> The undefinedness of how to lexically represent e.g. the aria-valuenow property with value 1/3 isn't great, but at least it's trying, whereas HTML5 only defines the mathematical concept of numbers as the consequence of a 140-word paragraph (and then defines a parsing algorithm that gives a different result)
  526. # [14:19] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: mhausenblas)
  527. # [14:21] * Joins: Ms2ger (~Ms2ger@91.181.47.87)
  528. # [14:24] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  529. # [14:26] * Joins: richt_ (~richt@pat-tdc.opera.com)
  530. # [14:26] * Quits: richt (~richt@guest.opera.com) (Read error: Connection reset by peer)
  531. # [14:27] * Quits: othermaciej (~mjs@2620:149:4:401:dc7d:87b3:3587:bad7) (Read error: Connection reset by peer)
  532. # [14:27] * othermaciej_ is now known as othermaciej
  533. # [14:28] * Joins: othermaciej_ (~mjs@17.203.15.144)
  534. # [14:28] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Client Quit)
  535. # [14:33] <hsivonen> huh. Hixie has allowed capital E as the exponent separator at some point...
  536. # [14:35] <gsnedders> hsivonen: Consistency with what ES5 allows in ToNumber
  537. # [14:38] * Joins: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de)
  538. # [14:39] * _bga is now known as bga_|away
  539. # [14:39] * bga_|away is now known as bga_
  540. # [14:39] * Joins: simplicity- (~simpli@unaffiliated/simplicity-)
  541. # [14:42] * Quits: myakura (~myakura@FL1-118-111-219-47.tky.mesh.ad.jp) (Read error: Operation timed out)
  542. # [14:42] * Quits: ezoe (~ezoe@112-68-245-203f1.kyt1.eonet.ne.jp) (Ping timeout: 240 seconds)
  543. # [14:42] * Quits: agektmr (~Adium@58x158x185x154.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
  544. # [14:45] * Joins: nimbu (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  545. # [14:45] * Parts: nimbu (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  546. # [14:53] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 248 seconds)
  547. # [14:57] * Joins: temp01 (~temp01@unaffiliated/temp01)
  548. # [15:03] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 246 seconds)
  549. # [15:06] * bga_ is now known as bga_|away
  550. # [15:06] * bga_|away is now known as bga_
  551. # [15:08] * Joins: temp01 (~temp01@unaffiliated/temp01)
  552. # [15:13] * Joins: MrOpposite (~mropposit@unaffiliated/mropposite)
  553. # [15:16] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  554. # [15:17] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Quit: Ex-Chat)
  555. # [15:18] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Client Quit)
  556. # [15:19] * Quits: kennyluck (~kennyluck@114-43-120-37.dynamic.hinet.net) (Quit: kennyluck)
  557. # [15:22] * Joins: shichuan (~Shi_Chuan@cm182.eta124.maxonline.com.sg)
  558. # [15:24] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Remote host closed the connection)
  559. # [15:25] * Joins: mpilgrim_ (~pilgrim@rrcs-24-206-36-125.midsouth.biz.rr.com)
  560. # [15:27] * Quits: nessy1 (~Adium@58-6-47-56.dyn.iinet.net.au) (Quit: Leaving.)
  561. # [15:32] * Joins: nessy (~Adium@58-6-47-56.dyn.iinet.net.au)
  562. # [15:33] * Joins: eikaas_ (~eikaas@79.161.4.102)
  563. # [15:36] * Quits: eikaas (~eikaas@79.161.4.102) (Ping timeout: 252 seconds)
  564. # [15:36] * eikaas_ is now known as eikaas
  565. # [15:44] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 246 seconds)
  566. # [15:46] * Joins: temp01 (~temp01@unaffiliated/temp01)
  567. # [15:46] * Joins: cgcardona (~cgcardona@adsl-68-126-42-253.dsl.pltn13.pacbell.net)
  568. # [15:46] * Quits: cgcardona (~cgcardona@adsl-68-126-42-253.dsl.pltn13.pacbell.net) (Changing host)
  569. # [15:46] * Joins: cgcardona (~cgcardona@unaffiliated/cgcardona)
  570. # [15:46] * Quits: Ankheg (~Ankheg@fs91-201-3-30.dubna-net.ru) (Ping timeout: 260 seconds)
  571. # [15:48] * Joins: Ankheg (~Ankheg@fs91-201-3-30.dubna-net.ru)
  572. # [15:50] * Joins: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net)
  573. # [15:50] * Quits: temp01 (~temp01@unaffiliated/temp01) (Quit: Poof.)
  574. # [15:51] * Joins: temp01 (~temp01@unaffiliated/temp01)
  575. # [15:54] * Quits: MrOpposite (~mropposit@unaffiliated/mropposite) (Remote host closed the connection)
  576. # [15:55] * Quits: temp01 (~temp01@unaffiliated/temp01) (Client Quit)
  577. # [15:57] * Joins: temp01 (~temp01@unaffiliated/temp01)
  578. # [16:02] * Quits: temp01 (~temp01@unaffiliated/temp01) (Quit: Poof.)
  579. # [16:03] * Joins: temp01 (~temp01@unaffiliated/temp01)
  580. # [16:11] * Quits: Ankheg (~Ankheg@fs91-201-3-30.dubna-net.ru) (Read error: Connection reset by peer)
  581. # [16:13] * Quits: hdhoang (~hdhoang@203.210.202.182) (Quit: Leaving.)
  582. # [16:15] * Joins: myakura (~myakura@FL1-118-111-219-27.tky.mesh.ad.jp)
  583. # [16:15] * Joins: hdhoang (~hdhoang@203.210.156.135)
  584. # [16:15] * Quits: nessy (~Adium@58-6-47-56.dyn.iinet.net.au) (Quit: Leaving.)
  585. # [16:17] * Joins: eikaas_ (~eikaas@79.161.4.102)
  586. # [16:18] * Joins: bentruyman (~bentruyma@li159-104.members.linode.com)
  587. # [16:20] * Quits: eikaas (~eikaas@79.161.4.102) (Ping timeout: 276 seconds)
  588. # [16:20] * eikaas_ is now known as eikaas
  589. # [16:26] * Joins: Jon47 (~jon47@204.56.125.50)
  590. # [16:33] * Quits: shichuan (~Shi_Chuan@cm182.eta124.maxonline.com.sg) (Quit: Leaving.)
  591. # [16:42] * Joins: saba (~foo@unaffiliated/saba)
  592. # [16:46] * Quits: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net) (Quit: cying)
  593. # [16:50] * Quits: hdhoang (~hdhoang@203.210.156.135) (Quit: Leaving.)
  594. # [16:56] * Quits: rimantas (~rimliu@93.93.57.193) (Quit: Leaving)
  595. # [16:59] <zcorpan> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12739 oooh ipv6 address
  596. # [17:00] * Joins: chriseppstein (~chris@99-34-231-235.lightspeed.sntcca.sbcglobal.net)
  597. # [17:02] * Quits: maikmerten (~merten@ls5dhcp197.cs.uni-dortmund.de) (Remote host closed the connection)
  598. # [17:04] * Joins: FireFly (~firefly@unaffiliated/firefly)
  599. # [17:06] * Quits: othermaciej (~mjs@c-24-6-209-6.hsd1.ca.comcast.net) (Quit: othermaciej)
  600. # [17:06] * othermaciej_ is now known as othermaciej
  601. # [17:07] * Joins: jgv_ (~jgv@67.217.137.10)
  602. # [17:08] * Quits: Maurice (~ano@77.222.73.150) (Quit: Disconnected...)
  603. # [17:09] * Quits: Martijnc (~Martijnc@d54C02C64.access.telenet.be) (Quit: Martijnc)
  604. # [17:13] * Joins: Martijnc (~Martijnc@d54C02C64.access.telenet.be)
  605. # [17:14] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
  606. # [17:17] * Quits: myakura (~myakura@FL1-118-111-219-27.tky.mesh.ad.jp) (Remote host closed the connection)
  607. # [17:22] * Joins: shichuan (~Shi_Chuan@cm182.eta124.maxonline.com.sg)
  608. # [17:22] * Quits: zcorpan (~zcorpan@c-8798e355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
  609. # [17:22] * Quits: oojacoboo (~jacob@96-32-175-233.dhcp.gwnt.ga.charter.com) (Quit: oojacoboo)
  610. # [17:23] * Quits: cgcardona (~cgcardona@unaffiliated/cgcardona) (Quit: zzzzz)
  611. # [17:36] * Quits: chriseppstein (~chris@99-34-231-235.lightspeed.sntcca.sbcglobal.net) (Quit: chriseppstein)
  612. # [17:37] * Joins: cying (~cying@173-228-29-224.dsl.static.sonic.net)
  613. # [17:38] * Quits: cying (~cying@173-228-29-224.dsl.static.sonic.net) (Read error: Connection reset by peer)
  614. # [17:38] * Joins: cying (~cying@173-13-176-101-sfba.hfc.comcastbusiness.net)
  615. # [17:42] * Joins: jwalden (~waldo@2620:101:8003:200:221:6aff:fe6e:d10)
  616. # [17:43] * Quits: MikeSmith (~MikeSmith@EM1-112-84-217.pool.e-mobile.ne.jp) (Quit: MikeSmith)
  617. # [17:52] * Joins: MikeSmith (~MikeSmith@EM1-112-84-217.pool.e-mobile.ne.jp)
  618. # [17:52] * Quits: erlehmann (~erlehmann@89.204.153.67) (Quit: Ex-Chat)
  619. # [17:55] <MikeSmith> recommendations for a perl module for parsing e-mail messages?
  620. # [17:56] <Ms2ger> My recommendation would be not to use perl :)
  621. # [17:56] <jgraham> Or to parse email messages
  622. # [17:56] <Rik`> Peter`: hey, I remember you have tools to check mozilla and webkit repositories?
  623. # [17:56] <Ms2ger> jgraham, ssh, I want him to parse them :)
  624. # [17:57] <MikeSmith> if perl's good enough for Hixie, it's good enough for me
  625. # [17:58] <MikeSmith> if there's a decent bugzilla library for python, I'd rather write it in python instead
  626. # [17:59] <MikeSmith> but I couldn't find any python bugzilla library
  627. # [17:59] <Philip`> Surely the solution to any parsing problem is regexps
  628. # [18:00] <Peter`> Rik`: Just WebKit and Chromium
  629. # [18:00] <Rik`> Peter`: are they public tools ?
  630. # [18:00] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  631. # [18:00] * Joins: boaz (~boaz@75-150-66-249-NewEngland.hfc.comcastbusiness.net)
  632. # [18:01] <Peter`> http://peter.sh/data/last-week/webkit/2011-20-monday.html
  633. # [18:01] <Peter`> http://peter.sh/data/last-week/chromium/2011-20-monday.html
  634. # [18:01] <Philip`> MikeSmith: Are these emails from random users that might be malformed etc?
  635. # [18:01] <Peter`> They're hardly tools, just a more convenient list of changesets
  636. # [18:01] <Ms2ger> I think Mozilla has python tools for interacting with bugzilla, but I don't know if the W3C instance has BZAPI set up
  637. # [18:01] <Ms2ger> Philip`, emails to public-html-comments
  638. # [18:01] * Joins: cgcardona (~cgcardona@adsl-99-154-225-102.dsl.pltn13.sbcglobal.net)
  639. # [18:01] * Quits: cgcardona (~cgcardona@adsl-99-154-225-102.dsl.pltn13.sbcglobal.net) (Changing host)
  640. # [18:01] * Joins: cgcardona (~cgcardona@unaffiliated/cgcardona)
  641. # [18:01] <MikeSmith> Philip`: yeah
  642. # [18:02] * Quits: cgcardona (~cgcardona@unaffiliated/cgcardona) (Client Quit)
  643. # [18:02] * jgraham always wonders if bzapi is a intentional reference to bz-the-person
  644. # [18:02] <Philip`> (It looks like stuff like Email::Simple might be nice enough but it says "you cannot expect it to cope well as the only parser between you and the outside world" which presumably isn't ideal here)
  645. # [18:03] <MikeSmith> Philip`: OK
  646. # [18:03] * Philip` has no personal experience of anything other than piping strings into sendmail, though
  647. # [18:03] <MikeSmith> Ms2ger: I don't think it does have BZAPI set up
  648. # [18:03] <Ms2ger> jgraham, not afaik
  649. # [18:04] * Joins: dbaron (~dbaron@nat/mozilla/x-xirqfpytotedghgl)
  650. # [18:04] <Ms2ger> MikeSmith, I'd argue that's your first step, then :)
  651. # [18:04] <Rik`> Peter`: that's exactly what I'm looking for, a more convenient way to list mozilla changesets
  652. # [18:04] <jgraham> Ms2ger: Surely I can't be the only person who thinks of that when I see it though :)
  653. # [18:04] <MikeSmith> Ms2ger: it just exposes a REST API anyway, right?
  654. # [18:04] <MikeSmith> not bound to python clients
  655. # [18:04] <Ms2ger> Yep
  656. # [18:05] <jgraham> Isn't the first step to upgrade to a newer bugzilla? Tht would solve lots of problems, right?
  657. # [18:05] <MikeSmith> sure
  658. # [18:05] <MikeSmith> and probably introduce a lot of others
  659. # [18:05] <Peter`> Rik`, I may have a look in setting this up for Mozilla as well, but won't have any bandwidth until next wek
  660. # [18:05] <Peter`> week*
  661. # [18:05] <Ms2ger> (https://github.com/toolness/pybugzilla, btw)
  662. # [18:06] <jgraham> MikeSmith: Maybe. But the W3C copy seems to be well behind
  663. # [18:06] <MikeSmith> jgraham: and anyway, I have to work with what I have
  664. # [18:06] * Quits: jochen__ (~jochen@nat/google/x-kxeimamaepfszzqv) (Ping timeout: 255 seconds)
  665. # [18:07] <Rik`> Peter`: don't worry, I was just looking for an existing tool so I don't have to write it :)
  666. # [18:08] * Quits: yijun (~yijun@2001:250:208:1666:21f:f3ff:fe52:9714) (Ping timeout: 255 seconds)
  667. # [18:08] <jgraham> mike][inq: f you wanted an upgrade you would presiumably point out that newer versions have more aria. Tht works like a cheat code, right? :)
  668. # [18:08] <jwalden> TabAtkins: ping
  669. # [18:09] * Joins: nielsle (~nielsle@4135136-cl69.boa.fiberby.dk)
  670. # [18:09] <TabAtkins> jwalden: pong
  671. # [18:09] <MikeSmith> jgraham: that's a good point, actually
  672. # [18:09] <MikeSmith> I didn't know they hard aria markup
  673. # [18:09] * jgraham apologieses if he disturbed mike][inq
  674. # [18:10] <jwalden> TabAtkins: are you aware that gradients in browsers don't actually have "no intrinsic dimensions"? like, background-image: gradient; background-size: 5px; acts as though the gradient had an intrinsic aspect ratio equal to that of the background positioning area
  675. # [18:10] * jgraham wonders how well dbolter gets on with bugzilla
  676. # [18:11] * Joins: jochen__ (~jochen@nat/google/x-socuxjpxppxjjtmf)
  677. # [18:11] <jwalden> TabAtkins: which seems a bit bizarre to me, but I'm not sure if you're trying to codify reality or codify a sensible behavior
  678. # [18:11] <TabAtkins> jwalden: the gradient itself has no dimensions. The gradient, when used, acquires dimensions equal to the element's background area.
  679. # [18:12] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  680. # [18:12] <TabAtkins> I'm not sure whether or not background-size:5px should affect things. Maybe?
  681. # [18:12] <jwalden> TabAtkins: the way css3 says to negotiate background-size, something with no dimensions and no aspect ratio and only one dimension constrained is rendered as if for 'contain'
  682. # [18:13] <jwalden> TabAtkins: which in that case means as large as possible while holding that specified dimension fixed
  683. # [18:13] * Quits: mpt (~mpt@canonical/mpt) (Read error: Operation timed out)
  684. # [18:13] <jwalden> TabAtkins: so background-size: 5px should per current spec algorithms give you 5px by (other dimension of BPA)
  685. # [18:14] * Quits: wolfman2000 (~wolfman20@rrcs-70-63-208-211.midsouth.biz.rr.com) (Remote host closed the connection)
  686. # [18:14] <jwalden> TabAtkins: in browsers now it gives you 5px by (whatever length gives a ratio equal to that of the BPA)
  687. # [18:15] * Joins: oojacoboo (~jacob@96-38-235-118.static.gwnt.ga.charter.com)
  688. # [18:16] <TabAtkins> jwalden: Okay, so I've looked at the spec again. That behavior *should* be a bug, but it's not entirely clear from the spec, because it's not well-defined how the background-properties map into the inputs to the size resolution algorithm in the Image Values spec.
  689. # [18:17] * Quits: smaug____ (~chatzilla@74.125.57.58) (Ping timeout: 246 seconds)
  690. # [18:17] <TabAtkins> The intent is that saying "background-size:5px" will make the "specified size" input be a 5px by 5px square, which immediately wins and sets the concrete object size to 5px by 5px.
  691. # [18:17] <jwalden> seems pretty clear to me how they map into the background-size algorithm in css3 b&b
  692. # [18:17] <jwalden> which takes as inputs only intrinsic width/height/aspect ratio
  693. # [18:19] * Joins: Bass2 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  694. # [18:19] * Joins: smaug____ (~chatzilla@74.125.57.58)
  695. # [18:21] <jwalden> fwiw I encountered this because I was implementing the css3 background-size algorithm for images partially or completely lacking intrinsic dimensions
  696. # [18:21] * Quits: Bass2 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Max SendQ exceeded)
  697. # [18:22] <jwalden> and the change to make gradients have no intrinsic ratio tripped a couple tests we have that expect the current behavior, rather than the one css3 b&b + images seems to specify
  698. # [18:23] <TabAtkins> I do need to resolve precisely where background-size sits in the size resolution order.
  699. # [18:23] * Quits: matjas (~matjas@91.182.178.25) (Quit: Computer has gone to sleep.)
  700. # [18:26] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
  701. # [18:27] * bga_ is now known as bga_|away
  702. # [18:27] * bga_|away is now known as bga_
  703. # [18:28] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: mhausenblas)
  704. # [18:28] * Joins: erlehmann (~erlehmann@89.204.153.67)
  705. # [18:29] * Quits: jgv_ (~jgv@67.217.137.10) (Quit: Computer has gone to sleep.)
  706. # [18:31] * Joins: chriseppstein (~chris@209.119.65.162)
  707. # [18:32] <TabAtkins> jwalden: So, background-size actually repeats most of what's in the Image Values algorithm.
  708. # [18:32] <jwalden> that's possible
  709. # [18:32] <jwalden> that seems bad
  710. # [18:33] <TabAtkins> If you provide 0, 1, or 2 dimensions, the behavior is identical to the Image Values algorithm, with the dimensions being the "specified size".
  711. # [18:33] <jwalden> seems like images should delegate to css3 b&b for background-size, which *does* actually have a specified algorithm
  712. # [18:33] <jwalden> unlike <img> or <object>
  713. # [18:33] <TabAtkins> It should be the other way around, actually. Image Values has the generic algorithm that everyone uses.
  714. # [18:33] <TabAtkins> But the B&B module was written before I wrote that algorithm, thus the current state of affairs.
  715. # [18:34] <TabAtkins> But anyway, the current behavior (where the gradient takes the ratio of the box as its intrinsic ratio) is a bug.
  716. # [18:34] <TabAtkins> It should size itself to the background-size box.
  717. # [18:34] <jwalden> wait
  718. # [18:34] <jwalden> so gradients *have* intrinsic dimensions then?
  719. # [18:35] <TabAtkins> no
  720. # [18:35] <jwalden> I guess I'm just confused how images would have anything more than a width (maybe), a height (maybe), and proportions (maybe)
  721. # [18:36] <TabAtkins> That is all they have, which means we're miscommunicating somehow.
  722. # [18:38] <jwalden> well, a gradient indicated by linear-gradient(...) has more than that somehow, because it has a different width/height/ratio depending on the context that uses it
  723. # [18:38] <jwalden> and the goal was, I thought, to make gradients a special case of images writ generally
  724. # [18:38] <TabAtkins> That's completely expected. You use a gradient as a background on a 200x100 box, the gradient will be resolved into a 200x100 image.
  725. # [18:39] <TabAtkins> This is described by the sizing algorithm.
  726. # [18:39] * Quits: dave_levin (~dave_levi@74.125.59.65) (Quit: dave_levin)
  727. # [18:39] * Joins: dave_levin (~dave_levi@nat/google/x-opozjnfbuwbzsbtg)
  728. # [18:39] <TabAtkins> Background-size *should* affect that computation, so writing "width:200px; height:100px; background-size:5px;" should resolve it into a 5x100 image.
  729. # [18:39] <jwalden> so "Gradients have no intrinsic dimensions." in 5. Gradients is just flat-out wrong?
  730. # [18:40] <jwalden> wait
  731. # [18:40] <TabAtkins> No, it's correct. I'm not sure what we're confusing each other over. ^_^
  732. # [18:40] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Quit: Now time for the weather. Tiffany?)
  733. # [18:40] <jwalden> background-size: 5px is b-s: 5px auto, which means the height is chosen to preserve the proportions of the image
  734. # [18:40] <jwalden> which for a gradient that ostensibly is 200x100 means you'd have 5px 2.5px rendered
  735. # [18:41] <TabAtkins> Yes. But gradients have no proportions before resolution, so it instead drops down to taking the height of the sizing area.
  736. # [18:41] <TabAtkins> You're confusing yourself by thinking about things in the wrong order.
  737. # [18:41] <jwalden> so, this idea of an image that doesn't have proportions, then does, is what's not represented by b&b
  738. # [18:41] <TabAtkins> You're imagining it goes "set size of element" -> "resolve gradient size" -> "apply background-size".
  739. # [18:43] <TabAtkins> jwalden: Well, it's unclear in B&B, because such a thing didn't exist at the time.
  740. # [18:43] <jwalden> I don't think I'm imagining anything -- I'm simply reading b&b which says that the size of the background is determined by consulting the specified background-size, then resolving any auto/contain/cover using the intrinsic dimensions width, height, and ratio of the image
  741. # [18:43] <TabAtkins> ...yes? That's correct, and consistent with what I've been saying.
  742. # [18:43] <jwalden> which exist independent of context, as part of the image itself
  743. # [18:43] <TabAtkins> Can you give me a situation that you believe is resolving incorrectly?
  744. # [18:46] <jwalden> 200x100 box, with gradient, background-size: 20px auto; 1) width is 20px as specified; 2) "An ‘auto’ value for one dimension is resolved by using the image's intrinsic ratio and the size of the other dimension, or failing that, using the image's intrinsic size, or failing that, treating it as 100%." => no intrinsic ratio to consult, no intrinsic size, fail to treating as 100% 3) rendered...
  745. # [18:46] <jwalden> ...size is 20px by 100px
  746. # [18:46] <TabAtkins> Yes, that's entirely correct.
  747. # [18:46] <TabAtkins> What part of that do you think is inconsisten with what I've said?
  748. # [18:46] <jwalden> I don't
  749. # [18:47] <jwalden> so I'm confused about how we're disagreeing, then, because I thought we were somehow
  750. # [18:47] <TabAtkins> We aren't. ^_^
  751. # [18:47] <jwalden> well then!
  752. # [18:47] <jwalden> glad that's settled
  753. # [18:47] <TabAtkins> Violent agreement it is!
  754. # [18:48] <TabAtkins> And, important note, the gradient itself is rendered into a 20x100 box, so color-stop positions done as lengths are resolved against that. They're not resolved against a 200px-wide box and then scaled down to 20px-wide.
  755. # [18:53] * Quits: Akilo (~kristof@lit75-1-81-57-239-230.fbx.proxad.net) (Read error: Operation timed out)
  756. # [18:53] * Quits: jwalden (~waldo@2620:101:8003:200:221:6aff:fe6e:d10) (Quit: captain, we're losing power in the batteries!)
  757. # [18:55] * Joins: maikmerten (~maikmerte@port-92-201-178-144.dynamic.qsc.de)
  758. # [18:57] * Joins: matijsb (~matijsb@5353CD69.cm-6-4d.dynamic.ziggo.nl)
  759. # [18:57] * Joins: MrOpposite (~mropposit@unaffiliated/mropposite)
  760. # [18:58] * Joins: jwalden (~waldo@2620:101:8003:200:222:68ff:fe15:af5c)
  761. # [18:59] * Joins: aho (~nya@fuld-590c7374.pool.mediaWays.net)
  762. # [19:04] * Joins: hdhoang (~hdhoang@203.210.156.135)
  763. # [19:05] * Quits: abarth (~abarth@173-164-128-209-SFBA.hfc.comcastbusiness.net) (Quit: abarth)
  764. # [19:05] * Quits: richt_ (~richt@pat-tdc.opera.com) (Remote host closed the connection)
  765. # [19:06] * Joins: ezoe (~ezoe@203-140-88-240f1.kyt1.eonet.ne.jp)
  766. # [19:06] * Joins: nimbu (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  767. # [19:06] * Parts: nimbu (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
  768. # [19:11] * Quits: shichuan (~Shi_Chuan@cm182.eta124.maxonline.com.sg) (Read error: Connection reset by peer)
  769. # [19:11] * Joins: shichuan (~Shi_Chuan@cm182.eta124.maxonline.com.sg)
  770. # [19:11] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  771. # [19:12] * bga_ is now known as bga_|away
  772. # [19:15] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  773. # [19:16] * Joins: mhausenblas_ (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  774. # [19:17] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (Ping timeout: 276 seconds)
  775. # [19:17] * Joins: ifette (~ifette@nat/google/x-drqnqbwybndsissn)
  776. # [19:17] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  777. # [19:18] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
  778. # [19:18] * bga_|away is now known as bga_
  779. # [19:20] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Ping timeout: 264 seconds)
  780. # [19:20] * mhausenblas_ is now known as mhausenblas
  781. # [19:20] * Quits: smaug____ (~chatzilla@74.125.57.58) (Ping timeout: 246 seconds)
  782. # [19:29] * bga_ is now known as bga_|away
  783. # [19:30] * bga_|away is now known as bga_
  784. # [19:33] * dglazkov|away is now known as dglazkov
  785. # [19:34] * Joins: wolfman2000 (~wolfman20@152-20-181-38.rev.uncw.edu)
  786. # [19:34] * Quits: maikmerten (~maikmerte@port-92-201-178-144.dynamic.qsc.de) (Remote host closed the connection)
  787. # [19:35] * Quits: MikeSmith (~MikeSmith@EM1-112-84-217.pool.e-mobile.ne.jp) (Ping timeout: 260 seconds)
  788. # [19:36] * Joins: hdhoang1 (~hdhoang@203.210.155.205)
  789. # [19:37] * Joins: miketaylr (~miketaylr@12.22.138.2)
  790. # [19:38] * Quits: hdhoang (~hdhoang@203.210.156.135) (Read error: Connection reset by peer)
  791. # [19:39] * Joins: hij1nx (~hij1nx@207.239.107.3)
  792. # [19:40] * Quits: jeremyselier (~Jeremy@92.103.127.226) (Ping timeout: 250 seconds)
  793. # [19:47] * Quits: ifette (~ifette@nat/google/x-drqnqbwybndsissn) (Quit: ifette)
  794. # [19:47] * Joins: ifette (~ifette@nat/google/x-bqfczxbqhlrubeba)
  795. # [19:49] * Quits: ifette (~ifette@nat/google/x-bqfczxbqhlrubeba) (Client Quit)
  796. # [19:49] * Joins: jamesr (~jamesr@nat/google/x-jfdqoqocxtkoolkw)
  797. # [19:49] * Joins: ifette (~ifette@nat/google/x-niwnevamkbmsqwcc)
  798. # [19:55] * Quits: eric_carlson (~eric_carl@17.203.15.27) (Quit: eric_carlson)
  799. # [19:55] * Joins: eric_carlson (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  800. # [19:58] * Joins: roc (~chatzilla@121.98.230.221)
  801. # [19:59] * Joins: stefan-_ (~music@swhpet3041.uni-trier.de)
  802. # [20:00] * Parts: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  803. # [20:00] * Quits: miketaylr (~miketaylr@12.22.138.2) (Quit: miketaylr)
  804. # [20:01] * Quits: jwalden (~waldo@2620:101:8003:200:222:68ff:fe15:af5c) (Quit: brb)
  805. # [20:03] <bga_> omg chome has --allow-all-activex flag
  806. # [20:03] <bga_> %)
  807. # [20:04] * Joins: jwalden (~waldo@2620:101:8003:200:222:68ff:fe15:af5c)
  808. # [20:11] * Quits: ifette (~ifette@nat/google/x-niwnevamkbmsqwcc) (Quit: ifette)
  809. # [20:14] * Joins: zdobersek (~zan@cpe-46-164-17-163.dynamic.amis.net)
  810. # [20:17] * Quits: hdhoang1 (~hdhoang@203.210.155.205) (Quit: Leaving.)
  811. # [20:20] * Quits: oojacoboo (~jacob@96-38-235-118.static.gwnt.ga.charter.com) (Quit: oojacoboo)
  812. # [20:24] * Joins: wolfman2_ (~wolfman20@152-20-181-38.rev.uncw.edu)
  813. # [20:27] * Quits: wolfman2000 (~wolfman20@152-20-181-38.rev.uncw.edu) (Ping timeout: 252 seconds)
  814. # [20:35] * Joins: ifette (~ifette@nat/google/x-ydmooigwpmogxfbx)
  815. # [20:37] * Joins: oojacoboo (~jacob@97-81-83-31.dhcp.athn.ga.charter.com)
  816. # [20:38] * Joins: espadrine (~thaddee_t@acces1527.res.insa-lyon.fr)
  817. # [20:40] <hsivonen> krijnh: it seems that the yellow highlights and the hiding of joins/parts is broken again
  818. # [20:48] * Quits: jwalden (~waldo@2620:101:8003:200:222:68ff:fe15:af5c) (Quit: brb)
  819. # [20:49] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: mhausenblas)
  820. # [20:52] * Joins: stevela (~anonymous@74.125.59.73)
  821. # [20:54] * Joins: miketaylr (~miketaylr@12.22.138.2)
  822. # [20:54] * Joins: jwalden (~waldo@2620:101:8003:200:222:68ff:fe15:af5c)
  823. # [20:54] * Joins: hij1nx_ (~hij1nx@207.239.107.3)
  824. # [20:54] * Joins: smaug____ (~chatzilla@78.41.210.66)
  825. # [20:54] * Joins: Smylers1 (~smylers@host109-157-249-110.range109-157.btcentralplus.com)
  826. # [20:54] * Quits: Smylers (~smylers@host109-157-249-110.range109-157.btcentralplus.com) (Ping timeout: 246 seconds)
  827. # [20:58] * Quits: hij1nx (~hij1nx@207.239.107.3) (Ping timeout: 276 seconds)
  828. # [20:58] * hij1nx_ is now known as hij1nx
  829. # [21:00] * Quits: bentruyman (~bentruyma@li159-104.members.linode.com) (Ping timeout: 246 seconds)
  830. # [21:01] * Quits: Martijnc (~Martijnc@d54C02C64.access.telenet.be) (Quit: Martijnc)
  831. # [21:02] * Joins: Transformer (~Transform@ool-4a59e397.dyn.optonline.net)
  832. # [21:02] * Quits: Transformer (~Transform@ool-4a59e397.dyn.optonline.net) (Excess Flood)
  833. # [21:11] <Hixie> ifette: yt?
  834. # [21:11] <ifette> hey
  835. # [21:11] * Joins: othermaciej_ (~mjs@17.203.15.180)
  836. # [21:11] <ifette> Hixie: yes
  837. # [21:11] <Hixie> hey
  838. # [21:11] <Hixie> are the protocol updates ready?
  839. # [21:12] <Hixie> our respective chairs are getting all antsy
  840. # [21:12] <Hixie> dunno why they get to be antsy, but it is what it is
  841. # [21:12] <ifette> Hixie: there's a few other changes that need to make it out in -08, e.g. reviews that came in from the TSV area director, some changes around ping/pong, etc
  842. # [21:12] <ifette> I have a draft that incorporates hooks for you already
  843. # [21:12] * Quits: erlehmann (~erlehmann@89.204.153.67) (Read error: Connection reset by peer)
  844. # [21:12] <ifette> but there's a bit more work before it can be called -08
  845. # [21:12] <Hixie> cool, that'll work
  846. # [21:12] <ifette> i will send it to you via email
  847. # [21:13] <Hixie> thanks
  848. # [21:13] * Hixie doesn't really care about version numbers :-)
  849. # [21:13] * Joins: sephr (~Eli@c-98-235-63-240.hsd1.pa.comcast.net)
  850. # [21:13] * Quits: Rik` (~Rik`@mozilla-paris-253-99.cnt.nerim.net) (Remote host closed the connection)
  851. # [21:14] * Joins: hdhoang (~hdhoang@203.210.155.205)
  852. # [21:15] <ifette> Hixie: it's sent. I need to run, have a lunch meeting.
  853. # [21:15] <Hixie> later
  854. # [21:15] <Hixie> thanks
  855. # [21:15] <ifette> I think I defined everything (including how to send and receive data, sigh)
  856. # [21:16] <ifette> afk
  857. # [21:16] * Quits: ifette (~ifette@nat/google/x-ydmooigwpmogxfbx) (Quit: ifette)
  858. # [21:16] <Hixie> ok let's see if i can find the things i was supposed to update!
  859. # [21:18] <Hixie> aha, i have a folder for websocket issues
  860. # [21:18] <Hixie> perfect
  861. # [21:22] <Ms2ger> Hixie, our implementers are getting antsy too ;)
  862. # [21:23] <Hixie> they have a valid reason to be antsy
  863. # [21:24] <smaug____> Ms2ger: if you saw my bug comment, I was truly just wondering where the discussion about API changes is happening. Since I don't recall such emails in WebApps
  864. # [21:25] <Ms2ger> Didn't mean to suggest anything else
  865. # [21:26] <smaug____> well, Hixie might know where the discussion about changes to WebSocket API is happening :9
  866. # [21:26] <smaug____> :)
  867. # [21:26] <Ms2ger> In his IMAP folders? :)
  868. # [21:27] <Hixie> whatwg, webapps, and w3c bugzilla
  869. # [21:28] * Joins: weinig (~weinig@2620:149:4:401:223:32ff:feaf:7f36)
  870. # [21:29] <smaug____> Hixie: sicking mentioned something about adding open()
  871. # [21:29] <smaug____> I can't really find any email about that
  872. # [21:29] <sicking> smaug____: have you looked at the bug?
  873. # [21:29] <Hixie> i have no plans to add open(), but there have been some mails about it
  874. # [21:29] <Hixie> i haven't yet read all the feedback though
  875. # [21:29] <smaug____> sicking: ah, you're awake!
  876. # [21:30] <Hixie> so maybe there is some reason to add it that i am not yet aware of
  877. # [21:30] * sicking is in meeting
  878. # [21:30] * Joins: erlehmann (~erlehmann@89.204.137.125)
  879. # [21:30] <smaug____> oh, right, I'm not in EET, atm
  880. # [21:30] <sicking> Hixie: last i looked, binary data and redirects were easier if we had .open
  881. # [21:30] <Hixie> (so far the only argument i've seen is "you can't hook the event listeners before the events fire if you don't have open()", which is false)
  882. # [21:30] <Hixie> sicking: i look forward to coming across the relevant feedback :-)
  883. # [21:31] <Hixie> i can't see how it would affect either of those, but i'm certainly happy to find out
  884. # [21:31] * Parts: shichuan (~Shi_Chuan@cm182.eta124.maxonline.com.sg)
  885. # [21:31] <sicking> Hixie: for binary data, you want to choose which format you want the result (blob or arraybuffer)
  886. # [21:31] <sicking> Hixie: which you can do after opening, but you risk the UA wasting time converting
  887. # [21:32] <Ms2ger> Hixie, if you had time to look at http://www.w3.org/Bugs/Public/show_bug.cgi?id=12742 , that would be nice
  888. # [21:32] <Ms2ger> (Turns out someone is implementing meter)
  889. # [21:32] <Hixie> Ms2ger: on it
  890. # [21:32] <smaug____> sicking: couldn't you just give all that information as parameters to ctor?
  891. # [21:32] <Hixie> sicking: why would the UA spend any time converting? surely the behind-the-scenes storage is identical
  892. # [21:32] <Hixie> sicking: my plan was to just expose both
  893. # [21:33] <sicking> smaug____: sure, but that means there's two APIs for choosing format. You need the ability to change format after receiving messages
  894. # [21:33] <smaug____> aha
  895. # [21:33] <smaug____> ok, I thought there would be one socket for each type
  896. # [21:33] <sicking> Hixie: if we first store to a blob, and then the page says "i want array buffers", we wasted time streaming to disk and then reading back into memory
  897. # [21:33] <Hixie> (for each message, just do .getDataAsBlob() or .getDataAsArrayBuffer() or whatnot and once you've done it the shop is closed and that's it)
  898. # [21:33] <Hixie> sicking: why would you stream to disk?
  899. # [21:33] <Hixie> sicking: just have the blob be memory-backed
  900. # [21:34] <sicking> Hixie: if you're receiving a huge thing
  901. # [21:34] <Hixie> why would the size matter
  902. # [21:34] <Hixie> you just memory map something that can be paged out
  903. # [21:34] <sicking> the whole reason you'd ever want to use blobs at all, is that the data is so large that you would rather not keep it in memory
  904. # [21:34] <sicking> that's the only reason you'd ever use a blob with websocket
  905. # [21:34] <sicking> or XHR
  906. # [21:35] <Hixie> whether it's in the ram chips or the disk cache or the disk or any number of other places seems like something the OS should take care of
  907. # [21:35] <Hixie> you just give the OS the pile of data, ask for some address space for it, and let it figure it out
  908. # [21:35] <sicking> Hixie: no, you don't want to have the same API for managing 4 bytes as for 4MB
  909. # [21:35] <Hixie> Ms2ger: in what sense is it ambiguous? i don't follow the bug.
  910. # [21:36] <sicking> Hixie: that's the same reason we have different APIs for <video> and <img.
  911. # [21:36] <sicking> <img>
  912. # [21:36] <sicking> you need to think differently when you handle large amounts of data
  913. # [21:36] <Hixie> we have different apis for <video> and <img> because <video> can be stopped and started and <img> can't
  914. # [21:36] <Hixie> not because they are different sizes
  915. # [21:36] <sicking> i disagree
  916. # [21:36] <Hixie> as the person who wrote the api, i am pretty sure i'm confident of the reasoning that led to the api :-)
  917. # [21:37] <sicking> Hixie: the buffering APIs on <video> has nothing to do with start/stop
  918. # [21:37] <Hixie> well sure, there's nothing to buffer for <img>, you always have to show all of it
  919. # [21:37] <sicking> right
  920. # [21:37] <Hixie> what's that got to do with 4 bytes vs 4 MB?
  921. # [21:37] <Hixie> if the 4MB is a PNG, you need all of it
  922. # [21:38] <Hixie> if the 400 bytes is a WebM video, you can use buffering APIs
  923. # [21:38] <sicking> so my point is that if you want to be able to manage large amounts of data, you need separate APIs for doing so efficently
  924. # [21:38] <Hixie> i don't think the size is the important factor here
  925. # [21:38] <sicking> if we had the same APIs for managing Blobs as for say Strings, people will write more inefficient code
  926. # [21:39] <Hixie> Strings vs Blob is a red herring, since the difference there is one of encodings
  927. # [21:39] <Hixie> Blob vs ArrayBuffer is the better comparison
  928. # [21:39] <Hixie> and the difference there is just what you're goign to do with it, not the size
  929. # [21:39] <sicking> that doesn't make it a red herring
  930. # [21:40] <sicking> there are multiple differences I agree
  931. # [21:40] <Hixie> you can have a 10 bytes Blob and a 10MB ArrayBuffer and not be doing anything wrong
  932. # [21:40] * Joins: MikeSmith (~MikeSmith@EM1-113-116-19.pool.e-mobile.ne.jp)
  933. # [21:40] <Ms2ger> Hixie, so, what would document.createElement("meter").max return?
  934. # [21:40] <Hixie> and vice versa
  935. # [21:40] <sicking> Hixie: except that you'll likely end up with inefficent code
  936. # [21:41] <sicking> Hixie: you want APIs where expensive operations feel expensive, and cheap operations feel cheap
  937. # [21:41] <hsivonen> so now after protocol delays we are going to have API delays before Web Sockets become an unprefixed interoperable part of the Web platform?
  938. # [21:41] <Hixie> Ms2ger: 0.0
  939. # [21:41] <Hixie> hsivonen: if by "delays" you mean "a couple of days"
  940. # [21:41] <smaug____> hsivonen: and Chrome continues to ship the non-prefixed old API/protocol
  941. # [21:41] <Hixie> sicking: sure
  942. # [21:42] <Hixie> sicking: but that's not the difference here
  943. # [21:42] <sicking> Hixie: and copying 4 bytes and 4MB takes different time
  944. # [21:42] <Hixie> sicking: Blob is about handling an opaque set of bytes, ArrayBuffer is about reading the bytes.
  945. # [21:42] <Hixie> sicking: how they are backed is an implementation concern not exposed in the API.
  946. # [21:42] <sicking> Hixie: nope
  947. # [21:42] <hsivonen> Hixie: well, let's hope it's a just a couple of days plus one six-week development cycle
  948. # [21:42] <sicking> Hixie: ArrayBuffer is opaque
  949. # [21:42] <Ms2ger> That's what I thought, but the patch returns 1.0
  950. # [21:42] <Hixie> Ms2ger: better fix it then :-)
  951. # [21:42] <sicking> Hixie: both ArrayBuffer and Blob represent a bag of bytes
  952. # [21:43] <Hixie> sicking: a
  953. # [21:43] <Hixie> er
  954. # [21:43] <sicking> Hixie: which you can use other APIs to read from
  955. # [21:43] <The_8472> sicking, a bag does not impose ordering. an array does
  956. # [21:43] <Hixie> sicking: true, i forgot about FileReader
  957. # [21:43] * Joins: zdobersek1 (~zan@cpe-46-164-10-73.dynamic.amis.net)
  958. # [21:44] <sicking> Hixie: ArrayBuffer represents a size small enough that it makes sense to keep in memory
  959. # [21:44] * Quits: zdobersek (~zan@cpe-46-164-17-163.dynamic.amis.net) (Ping timeout: 260 seconds)
  960. # [21:45] <Ms2ger> So, want to add, say, "(For the purposes of reflection, these attributes don't have default values.)"? :)
  961. # [21:45] <Hixie> sicking: i disagree that there is a size implication to Blob or ArrayBuffer.
  962. # [21:45] <Hixie> Ms2ger: there's like a 100 attributes in the spec to which that would apply. It would just make the spec bigger without improving its quality.
  963. # [21:45] <sicking> Hixie: may i steal your editor argument? ;-)
  964. # [21:45] * Quits: oojacoboo (~jacob@97-81-83-31.dhcp.athn.ga.charter.com) (Quit: oojacoboo)
  965. # [21:45] * Quits: wolfman2_ (~wolfman20@152-20-181-38.rev.uncw.edu) (Remote host closed the connection)
  966. # [21:46] <Hixie> sicking: you can certainly argue that the specs intended for there to be a difference
  967. # [21:46] <Ms2ger> K
  968. # [21:46] <Hixie> sicking: but they don't have one in the finished product
  969. # [21:46] <sicking> Hixie: they are certainly optimized for the usecase of being different size
  970. # [21:46] <sicking> Hixie: people can always abuse any API if that's what you mean?
  971. # [21:47] <sicking> Hixie: this is why ArrayBuffer allows synchronous access, but Blob does not
  972. # [21:47] <Hixie> sicking: I would agree that ArrayBuffer is more optimal for in-memory data and Blob is more optimal for data that is stored on something with high latency
  973. # [21:47] <Hixie> sicking: but that's also independent of size
  974. # [21:48] <Hixie> sicking: if i have a gig of data in RAM, and one byte of data on a tape in an automated tape cassette deck system, it's gonna be quicker to read the entire gig than the one byte
  975. # [21:48] <Hixie> sicking: and ArrayBuffer would be appropriate for the former while Blob is appropriate for the latter
  976. # [21:48] <Hixie> sicking: and not vice versa
  977. # [21:48] <sicking> Hixie: right, so erm, i'm not gonna optimize the API for that computer
  978. # [21:49] <Hixie> "that computer" is also called "the cloud"
  979. # [21:49] <sicking> your cloud is backed by a one byte tape cassette?
  980. # [21:50] <Hixie> i didn't say the cassette only had one byte
  981. # [21:50] <Hixie> i just meant that you had one byte of interest on the tape
  982. # [21:50] <Hixie> and yes, the cloud is backed by tape backup
  983. # [21:50] <Hixie> (q.v. http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html)
  984. # [21:51] <sicking> so if you want a performant app, you should not use a ArrayBuffer that swaps to that disk
  985. # [21:51] <sicking> it'll work if you do, it'll just be slow
  986. # [21:52] <Hixie> and you shouldn't use a blob for the 1GB in-memory file, since you would have to convert the Blob to an ArrayBuffer to read it
  987. # [21:52] <Hixie> anyway i think the original argument is better expressed as "we don't want to have to keep the whole thing in memory if we don't have to"
  988. # [21:52] <Hixie> so if the author can give a hint that the data won't be immediately read, that would be a good hint to give
  989. # [21:53] <sicking> yes
  990. # [21:53] <sicking> well
  991. # [21:53] <sicking> as long as i can choose if i want the next message as an arraybuffer or a blob i'm happy
  992. # [21:53] <sicking> and we can disagree what the use cases are :)
  993. # [21:53] <Hixie> controlling the next message is probably not ideal either
  994. # [21:54] <Hixie> if the server tells you "i'm about to send a 1GB attachment" and then sends it, it might be too late by the time you process the event for the warning message to help the UA with the next message
  995. # [21:54] <sicking> so what do you propose?
  996. # [21:54] <Hixie> what you really want is a way for the script to tell the UA ahead of time which messages should be stored as Blobs and which shouldn't, or something like that...
  997. # [21:55] <Hixie> hmm
  998. # [21:55] * Joins: matjas (~matjas@91.182.178.25)
  999. # [21:55] <Hixie> do binary messages have any metadata?
  1000. # [21:55] <Hixie> or as they straight binary data?
  1001. # [21:55] <sicking> don't know
  1002. # [21:55] <Hixie> s/as/are/
  1003. # [21:55] * Hixie looks
  1004. # [21:56] <sicking> i think it also depends on what the client side is going to use the data for
  1005. # [21:56] <Hixie> man, this protocol got way more complicated
  1006. # [21:56] <sicking> if i know that all i'm gonna do with the data is to stick it in IndexedDB, then it's nice if i can just tell the socket to give me a blob
  1007. # [21:56] <sicking> this is sort of similar to the responseType property on XHR
  1008. # [21:57] <Hixie> no metadata, it seems
  1009. # [21:58] <Hixie> with XHR, you ask for the data ahead of time, though
  1010. # [21:58] <sicking> ok, i gotta take off
  1011. # [21:58] <Hixie> later
  1012. # [21:58] <sicking> you are with websocket too, no? by connecting
  1013. # [21:58] <Hixie> websocket is full-duplex, not request-response
  1014. # [21:59] <Hixie> you don't know that the next packet you get is going to be what you last asked for
  1015. # [21:59] <Hixie> it could be a random update
  1016. # [21:59] * Quits: smaug____ (~chatzilla@78.41.210.66) (Read error: Operation timed out)
  1017. # [21:59] <sicking> sure, i'm not sure I see the difference thoguh
  1018. # [22:00] <Hixie> say you ask for a big image you want to store somewhere
  1019. # [22:00] <Hixie> so you set the websocket object to give you a blob
  1020. # [22:01] <Hixie> but the next message you get from the server is a binary status message
  1021. # [22:01] <Hixie> and only then do you get the big image
  1022. # [22:01] <sicking> well, that can easily be solved on a app level
  1023. # [22:01] <sicking> just send one message saying what's about to come next
  1024. # [22:01] <Hixie> by the time you are processing that message, it's too late
  1025. # [22:02] <Hixie> that message and the binary data will probably all be read from the same IP packet and processed by the UA before any events are fired
  1026. # [22:02] <sicking> if it's that small amount of data then it doesn't really matter though
  1027. # [22:02] <sicking> the implementation can just create a memory backed blob
  1028. # [22:03] <sicking> effectively the same thing happens with XHR
  1029. # [22:03] <Hixie> you're going to be getting a lot of data very quickly
  1030. # [22:03] * Quits: othermaciej (~mjs@17.203.15.144) (Quit: othermaciej)
  1031. # [22:03] * othermaciej_ is now known as othermaciej
  1032. # [22:03] <sicking> by the time you fire the HEADERS_RECEIVED event, the body will be full on streaming
  1033. # [22:03] <Hixie> if the main UI thread is busy doing something like whosing an alert(), you're going to get the whole 4MB before you have had a chance to tell the script about the warning message
  1034. # [22:04] <sicking> sure
  1035. # [22:04] <sicking> same thing with XHR
  1036. # [22:04] <Hixie> well i can't speak for XHR's design
  1037. # [22:04] <sicking> the page can just choose not to put up an alert
  1038. # [22:04] <sicking> this is all about giving the page the tools to manage its resources
  1039. # [22:05] <sicking> it can do so well, or it can do so crappily
  1040. # [22:05] <Hixie> are we talking about an API that forces teh response to be just one type, like XHR, or an API that gives a hint but doesn't preclude getting the other type?
  1041. # [22:06] <Hixie> i don't think it's realistic to expect a whole event loop spin to occur fast enough after the first message is processed to be useful for the next message
  1042. # [22:06] <sicking> well, if the app strings two messages together, it's got basically the same capabilities as XHR, right?
  1043. # [22:07] <Hixie> i can't speak for XHR's design. As far as I can tell, allowing responseType to be set in the headers stage nullifies any implementation benefit for that API.
  1044. # [22:07] <sicking> out of curiosity, what bandwidth are you envisioning?
  1045. # [22:09] <Hixie> well i dunno. in some parts of the world we're still talking 24kbps, but in other parts of the world we're seeing deployment of residential terabit broadband
  1046. # [22:09] <Hixie> but since the cpu is probably somewhat proportional to the bandwidth, i doubt that matters much
  1047. # [22:10] <sicking> my experience is that downloading 4MB takes a lot longer than spinning the event loop a couple of times
  1048. # [22:10] <sicking> but i haven't run any numbers
  1049. # [22:10] * Joins: ap (~ap@2620:149:4:401:226:4aff:fe14:aad6)
  1050. # [22:11] * Joins: ttepasse (~ttepasse@dslb-088-077-092-207.pools.arcor-ip.net)
  1051. # [22:11] <sicking> ok, taking off for real
  1052. # [22:12] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Remote host closed the connection)
  1053. # [22:13] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  1054. # [22:13] <Hixie> seems like the better solution is to just have the UA stream to memory at first, then past a dynamic threshold switch to streaming to disk
  1055. # [22:13] * Joins: bfrohs (~bfrohs@smtp.forewordinternal.com)
  1056. # [22:14] <Hixie> the threshold being derived by inspection, based on the frequency with which getAsBlob() is called vs getAsBuffer() for each particular size
  1057. # [22:14] <Hixie> maybe on a per-origin basis
  1058. # [22:15] <Hixie> although i have to wonder, won't many protocols consist of a binary prefix saying what kind of data it is followed by something to be read as a blob?
  1059. # [22:15] <Hixie> instead of a text frame followed by a binary frame?
  1060. # [22:16] <Hixie> i guess the latter is easier with this api
  1061. # [22:16] <bfrohs> http://bit.ly/iUaRu8 - Is it just me, or are the controls coming out red? (in chrome, fine in firefox)
  1062. # [22:17] <bfrohs> And just to make sure I'm not crazy, "input" should *not* work in css for "audio" controls, correct?
  1063. # [22:18] <TabAtkins> They shouldn't. But they do, because our implementation is bad right now.
  1064. # [22:18] <TabAtkins> Near future, controls will be properly hidden under a shadow dom, and won't match selectors in the outer page.
  1065. # [22:22] <bfrohs> TabAtkins: kaykay, thanks!
  1066. # [22:24] * Joins: oojacoboo (~jacob@96-32-175-233.dhcp.gwnt.ga.charter.com)
  1067. # [22:28] * Joins: othermaciej_ (~mjs@17.203.15.180)
  1068. # [22:28] * Quits: othermaciej (~mjs@17.203.15.180) (Read error: Connection reset by peer)
  1069. # [22:28] * othermaciej_ is now known as othermaciej
  1070. # [22:29] * Quits: matjas (~matjas@91.182.178.25) (Quit: Computer has gone to sleep.)
  1071. # [22:37] <TabAtkins> Hixie: Just published Lists WD, a full 8.5 years after your last WD. I know that's a record in CSS; I wonder how it compares across the W3C?
  1072. # [22:37] * Joins: ifette (~ifette@nat/google/x-hbelmfunvzydlszr)
  1073. # [22:38] * Joins: Akilo (~kristof@89-159-215-142.rev.numericable.fr)
  1074. # [22:39] * Quits: zdobersek1 (~zan@cpe-46-164-10-73.dynamic.amis.net) (Quit: Leaving.)
  1075. # [22:39] <Hixie> TabAtkins: meh, publishing WDs is so last decade
  1076. # [22:40] * heycam|away is now known as heycam
  1077. # [22:40] <TabAtkins> Whatevs.
  1078. # [22:40] * Quits: msucan (~robod@92.86.247.27) (Quit: .)
  1079. # [22:41] * Quits: simplicity- (~simpli@unaffiliated/simplicity-) (Quit: simplicity-)
  1080. # [22:41] * Quits: Ms2ger (~Ms2ger@91.181.47.87) (Quit: nn)
  1081. # [22:42] <zewt> last decade, or, well, 8.5 years ago at any rate
  1082. # [22:42] <bfrohs> TabAtkins: Section 7 Using Content as Markers: The 'marker' value for 'display'... Did you mean to have 'same as CSS2.1' listed for each property?
  1083. # [22:42] * Quits: Akilo (~kristof@89-159-215-142.rev.numericable.fr) (Ping timeout: 240 seconds)
  1084. # [22:42] * Quits: roc (~chatzilla@121.98.230.221) (Ping timeout: 246 seconds)
  1085. # [22:43] <TabAtkins> bfrohs: Yes. The preprocessor that generates the property table at the end gets angry without all the values.
  1086. # [22:49] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
  1087. # [22:49] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  1088. # [22:51] * Quits: ifette (~ifette@nat/google/x-hbelmfunvzydlszr) (Remote host closed the connection)
  1089. # [22:52] * Joins: ifette (~ifette@nat/google/x-ccjonjzwvfosndfd)
  1090. # [22:54] * Quits: ifette (~ifette@nat/google/x-ccjonjzwvfosndfd) (Remote host closed the connection)
  1091. # [22:54] * Joins: ifette (~ifette@nat/google/x-dyarjznhhezwhgzz)
  1092. # [22:55] * Joins: smaug____ (~chatzilla@78.41.210.66)
  1093. # [22:56] * Joins: Akilo (~kristof@89-159-215-142.rev.numericable.fr)
  1094. # [22:56] * Quits: ifette (~ifette@nat/google/x-dyarjznhhezwhgzz) (Remote host closed the connection)
  1095. # [22:57] * Joins: ifette (~ifette@nat/google/x-ynvinkpwoqsywtxg)
  1096. # [22:57] * Parts: bfrohs (~bfrohs@smtp.forewordinternal.com)
  1097. # [22:58] * Quits: saba (~foo@unaffiliated/saba) (Quit: leaving)
  1098. # [23:00] * bga_ is now known as bga_|away
  1099. # [23:03] * Quits: dbaron (~dbaron@nat/mozilla/x-xirqfpytotedghgl) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1100. # [23:04] * Joins: dbaron (~dbaron@nat/mozilla/x-yutfsjukcjlgeobf)
  1101. # [23:05] * Quits: hdhoang (~hdhoang@203.210.155.205) (Quit: Leaving.)
  1102. # [23:10] * Quits: Necrathex (~nectop@82-170-160-25.ip.telfort.nl) (Remote host closed the connection)
  1103. # [23:16] * Joins: roc (~chatzilla@203-97-204-82.dsl.clear.net.nz)
  1104. # [23:17] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  1105. # [23:21] * Quits: nielsle (~nielsle@4135136-cl69.boa.fiberby.dk) (Quit: Ex-Chat)
  1106. # [23:21] * bga_|away is now known as bga_
  1107. # [23:23] * Joins: yijun (~yijun@211.82.74.16)
  1108. # [23:25] * Quits: ap (~ap@2620:149:4:401:226:4aff:fe14:aad6) (Read error: Connection reset by peer)
  1109. # [23:25] * Joins: ap (~ap@17.203.14.199)
  1110. # [23:25] * Quits: yijun (~yijun@211.82.74.16) (Remote host closed the connection)
  1111. # [23:26] * Joins: yijun (~yijun@2001:250:208:1666:21f:f3ff:fe52:9714)
  1112. # [23:29] * Joins: ako (~nya@fuld-590c6783.pool.mediaWays.net)
  1113. # [23:31] * Quits: erlehmann (~erlehmann@89.204.137.125) (Quit: Ex-Chat)
  1114. # [23:32] * Quits: aho (~nya@fuld-590c7374.pool.mediaWays.net) (Ping timeout: 250 seconds)
  1115. # [23:36] * Joins: jdaggett (~jdaggett@y227145.dynamic.ppp.asahi-net.or.jp)
  1116. # [23:36] * Quits: Akilo (~kristof@89-159-215-142.rev.numericable.fr) (Ping timeout: 252 seconds)
  1117. # [23:43] * Joins: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1)
  1118. # [23:44] * Quits: ttepasse (~ttepasse@dslb-088-077-092-207.pools.arcor-ip.net) (Ping timeout: 246 seconds)
  1119. # [23:47] * Quits: miketaylr (~miketaylr@12.22.138.2) (Quit: miketaylr)
  1120. # [23:49] * Quits: matijsb (~matijsb@5353CD69.cm-6-4d.dynamic.ziggo.nl) (Quit: Leaving.)
  1121. # [23:49] * Quits: cying (~cying@173-13-176-101-sfba.hfc.comcastbusiness.net) (Quit: cying)
  1122. # [23:49] * Joins: smaug_____ (~chatzilla@78.41.210.66)
  1123. # [23:51] * Quits: smaug____ (~chatzilla@78.41.210.66) (Ping timeout: 264 seconds)
  1124. # [23:51] * smaug_____ is now known as smaug____
  1125. # [23:51] * Quits: chriseppstein (~chris@209.119.65.162) (Quit: chriseppstein)
  1126. # [23:55] * Joins: nessy (~Adium@58-6-47-56.dyn.iinet.net.au)
  1127. # [23:59] * Joins: chriseppstein (~chris@dsl092-049-179.sfo4.dsl.speakeasy.net)
  1128. # Session Close: Wed May 25 00:00:00 2011

The end :)