/irc-logs / w3c / #css / 2009-02-13 / end

Options:

  1. # Session Start: Fri Feb 13 00:00:00 2009
  2. # Session Ident: #css
  3. # [00:09] * Quits: shepazu (schepers@128.30.52.30) (Client exited)
  4. # [00:41] * Quits: fantasai (fantasai@71.138.141.152) (Quit: Lost terminal)
  5. # [00:42] * Joins: shepazu (schepers@128.30.52.30)
  6. # [01:00] * Joins: fantasai (fantasai@71.138.141.152)
  7. # [01:14] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  8. # [01:16] <dino> anne?
  9. # [01:16] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  10. # [01:43] * Joins: shepazu (schepers@128.30.52.30)
  11. # [02:04] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  12. # [02:15] <jdaggett> dino: ping
  13. # [02:16] <dino> hi jdaggett
  14. # [02:16] <jdaggett> just wondering, are you planning on attending the Tokyo F2F?
  15. # [02:16] <dino> jdaggett: no.
  16. # [02:16] <dino> i'd love to though :)
  17. # [02:17] <jdaggett> would you be able to dial in for discussions of apple specs?
  18. # [02:17] <dino> jdaggett: definitelu
  19. # [02:18] <jdaggett> cool
  20. # [02:18] <dino> definitely
  21. # [02:18] <jdaggett> what time is it now where you are?
  22. # [02:18] <jdaggett> 11?
  23. # [02:18] <dino> 12
  24. # [02:19] <jdaggett> so discussions during the afternoon your time are good?
  25. # [02:19] <dino> actually, my morning would be better for me
  26. # [02:19] <jdaggett> ok
  27. # [02:19] <jdaggett> it would probably slide into lunch
  28. # [02:19] <jdaggett> since 9am here is 11am your time
  29. # [02:20] <dino> well, whatever works is fine
  30. # [02:20] <jdaggett> good, good
  31. # [02:20] <jdaggett> thanks
  32. # [02:20] <dino> i can be available whenever
  33. # [02:41] * Quits: sylvaing (sylvaing@131.107.0.72) (Ping timeout)
  34. # [02:53] * Joins: Lachy (Lachlan@85.196.122.246)
  35. # [03:03] * Joins: sylvaing (sylvaing@70.7.87.182)
  36. # [03:48] * Quits: sylvaing (sylvaing@70.7.87.182) (Ping timeout)
  37. # [03:53] * Quits: fantasai (fantasai@71.138.141.152) (Ping timeout)
  38. # [04:23] * Quits: dbaron (dbaron@63.245.220.246) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  39. # [04:23] * Joins: shepazu (schepers@128.30.52.30)
  40. # [04:39] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  41. # [07:44] * Joins: sylvaing (sylvaing@98.247.143.102)
  42. # [07:50] * Joins: fantasai (fantasai@71.138.141.152)
  43. # [08:02] * Quits: sylvaing (sylvaing@98.247.143.102) (Ping timeout)
  44. # [09:16] * Quits: fantasai (fantasai@71.138.141.152) (Quit: Lost terminal)
  45. # [09:16] * Joins: fantasai (fantasai@71.138.141.152)
  46. # [09:21] * Quits: fantasai (fantasai@71.138.141.152) (Ping timeout)
  47. # [10:03] <anne> dino, yes?
  48. # [10:03] <dino> hey
  49. # [10:03] <anne> dino, you being on the other end of the world and me going to bed at reasonable hours does not make this easy
  50. # [10:03] <anne> oh, you're here :)
  51. # [10:03] <dino> so, i was thinking of implementing parts of cssom view
  52. # [10:03] <dino> particularly, the API to query media rules
  53. # [10:04] <anne> cool!
  54. # [10:04] <dino> i didn't know you'd written that spec
  55. # [10:04] <dino> http://webkit.org/specs/MediaQueriesExtensions.html
  56. # [10:04] <dino> was what i was going to do (see section 6)
  57. # [10:04] <anne> aah, I saw that and wanted to e-mail you about it :)
  58. # [10:04] <dino> but your approach is better
  59. # [10:04] <anne> ta
  60. # [10:05] <dino> now.. i have comments
  61. # [10:05] <dino> not on that one
  62. # [10:05] <dino> but we need the point mapping APIs to be able to take transforms into account
  63. # [10:05] <dino> we already have implemented some methods for mapping a point from a node into page coordinates
  64. # [10:05] <dino> (custom methods, currently only on iphone)
  65. # [10:06] <anne> doesn't it take transforms into account autometically?
  66. # [10:06] <anne> i'd assume hit testing does not assume nothing is transformed...
  67. # [10:07] <dino> in our case we need to be able to map an arbitrary x,y point into page coords
  68. # [10:07] <dino> sure, hit testing gets extremely complicated with transforms (especially 3d)
  69. # [10:07] <dino> we make sure elementAtPoint and so on works
  70. # [10:09] <dino> anne: trying to find the documentation on what we implement
  71. # [10:10] <anne> kk, when you say arbitrary x,y point into page coords do you mean arbitrary x,y point on the viewport into coords for the canvas or something?
  72. # [10:10] <dino> right
  73. # [10:10] <dino> and the other way around
  74. # [10:10] <anne> interesting
  75. # [10:10] <dino> see the end of the CSS Transforms spec
  76. # [10:11] <dino> now on w3.org!!
  77. # [10:11] <dino> we add a Point class
  78. # [10:11] <dino> and then add this to Window: Point convertPointFromPageToNode(in Node node, in Point point);
  79. # [10:11] <dino> Point convertPointFromNodeToPage(in Node node, in Point point);
  80. # [10:12] <dino> your CSSOM View api is one way only
  81. # [10:12] <dino> and also does bounding rects
  82. # [10:13] <dino> are remember that with rotations, things are not rects
  83. # [10:13] <dino> or you want more accurate than a rect
  84. # [10:13] <dino> you want a quad
  85. # [10:13] <dino> make sense?
  86. # [10:13] <anne> I think I still follow, yes
  87. # [10:14] <dino> so, do you think you could add in methods to allow us to do conversion
  88. # [10:14] <dino> ?
  89. # [10:15] <dino> it would be nice to have Point and Rect interfaces
  90. # [10:15] <anne> would it be ClientPoint, effectively?
  91. # [10:15] <dino> could be
  92. # [10:15] <dino> doesn't matter that much
  93. # [10:15] <anne> actually, probably not
  94. # [10:16] <dino> it's just Point, nothing clienty about it :)
  95. # [10:16] <anne> I suppose in convertPointFromNodeToPage it is relative to the element
  96. # [10:16] <anne> the definition of getClientRects() still works for transforms right?
  97. # [10:17] <anne> i.e. there's still a bounding box
  98. # [10:17] <dino> yes
  99. # [10:17] <anne> euh, border box
  100. # [10:17] <dino> but that isn't always useful when there are transforms
  101. # [10:17] <dino> eg. rotate(45deg)
  102. # [10:17] <anne> yeah, so we need new sets of methods?
  103. # [10:17] <dino> i think so
  104. # [10:17] <anne> getClientCoordinates() or something?
  105. # [10:18] <dino> we have one internally on the phone that returns a list of four points
  106. # [10:18] <anne> and have ClientCoordinates class which takes a list of points
  107. # [10:18] <anne> four is always enough?
  108. # [10:18] <dino> it's important to do it in one method call because there can be a lot of ugly math involved (building up a set of matrix multiplication)
  109. # [10:19] <dino> to JS though we only provide the method for a single point
  110. # [10:21] <anne> so you only have the APIs you listed above, nothing like getClientRects() ?
  111. # [10:22] <dino> yes
  112. # [10:22] <dino> correct
  113. # [10:22] <anne> and you're saying that having something like getClientRects() that takes into account transforms would be painful so you rather have the Point API?
  114. # [10:23] <dino> basically, we need something like convertPointFromPageToNode
  115. # [10:23] <dino> and the other way around too
  116. # [10:24] <dino> getClientRects is from Node To Page
  117. # [10:24] <dino> make sense?
  118. # [10:25] <dino> and we're sort of implementing this in public webkit at the moment, so there is a little time pressure :)
  119. # [10:25] <anne> yes, I'm just wondering whether we want your approach or a simple extension of what we have now
  120. # [10:25] <dino> we don't particularly like our approach
  121. # [10:25] <anne> e.g. now we have elementFromPoint() and getClientRects()
  122. # [10:25] <dino> but we needed to implement something for iPhone 2.0
  123. # [10:26] <anne> we could have elementFromPagePoint() and getClientCoords() or something like that
  124. # [10:26] <dino> yep, sounds good.
  125. # [10:26] <anne> or maybe just getBoundingClientCoords(); will you ever have multiple boxes?
  126. # [10:26] <dino> although, it isn't just about getting the element
  127. # [10:26] <dino> say, you want to position an object under the mouse
  128. # [10:27] <dino> but that object is in a complicated set of nested transforms
  129. # [10:27] <dino> what you need to know is, what top/left (or translate) do I need to put the object in the right place
  130. # [10:29] <dino> or, the other way around
  131. # [10:29] <anne> so you have a viewport coordinate and an element and you want to know how far they are apart?
  132. # [10:30] <dino> you want something at the top level of the document to track the position of something deeply nested and transformed
  133. # [10:30] <dino> you have a viewport coordinate and you want to know what that corresponds to in the coordinate system of a child
  134. # [10:30] <dino> note that SVG, the greatest specification ever to have been written, has something like this too
  135. # [10:31] <anne> ooh, can't we juse reuse that API?
  136. # [10:31] <dino> looking it up
  137. # [10:36] <dino> http://www.w3.org/TR/SVG11/types.html#InterfaceSVGLocatable
  138. # [10:36] <dino> anne: that has the helpful functions, like getTransformToElement and getScreenCTM
  139. # [10:36] <dino> that would be enough
  140. # [10:37] <dino> since you can get the inverse to do the reverse mapping
  141. # [10:37] <dino> however, there is a small snag with 3d transforms, in that you can't always describe the transform as a matrix (if there has been flattening)
  142. # [10:37] <dino> that's why we pass points
  143. # [10:37] <dino> ie. the matrix might be impossible to generate, but we can apply the same logic of the transform to the point to get the result
  144. # [10:38] <anne> so they won't work?
  145. # [10:38] <dino> i think they are a great idea in general, and work perfectly for 2d stuff
  146. # [10:40] <dino> but don't always work for 3d
  147. # [10:41] <dino> anne: what if we talked about it internally and sent you a proposal?
  148. # [10:41] <dino> to www-style or something
  149. # [10:41] <anne> the only problem is that they return SVGMatrix
  150. # [10:41] <anne> yeah, that'd be great
  151. # [10:41] <anne> please tag it cssom-view
  152. # [10:42] <anne> [cssom-view] fancy new features or something
  153. # [10:42] <dino> we were hoping you'd have an solution right away
  154. # [10:42] <dino> but obviously you are useless
  155. # [10:42] <anne> haha
  156. # [10:42] <dino> the good news is that we are equally useless
  157. # [10:42] <dino> meanwhile, i want you to fix the CSSOM asap
  158. # [10:42] <dino> it's horrible
  159. # [10:42] <anne> wow yeah, I agree, wanna take over?
  160. # [10:43] * anne is sort of heads down changing Web security policies
  161. # [10:44] <dino> no, i don't
  162. # [10:44] <dino> i don't even want to do the specs that I'm actually implementing :)
  163. # [10:44] <dino> if I had my way i would erase everything and start over
  164. # [10:45] <anne> yeah, would be much neater if bytes actually consisted of 10 bits
  165. # [10:45] <dino> actually, i was thinking 0 bits
  166. # [10:45] <dino> much much easier
  167. # [10:49] <anne> true, if we could go that far back maybe make sure humans are perfect right from the start so we don't have to go through all this comittee trouble
  168. # [11:22] * Quits: timeless (timeless@65.75.195.122) (Ping timeout)
  169. # [11:38] <anne> http://crisp.tweakblogs.net/blog/1380/css-compliance-which-browser-gets-this-right.html hmm
  170. # [11:38] <anne> Bert, ^^
  171. # [11:40] * Bert in a meeting, will look later.
  172. # [11:43] <anne> meetings so early? ouch
  173. # [11:43] <anne> and thanks
  174. # [12:20] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  175. # [12:25] * Quits: anne (annevk@85.196.122.246) (Ping timeout)
  176. # [12:33] * Joins: Lachy (Lachlan@213.236.208.22)
  177. # [12:33] * Joins: anne (annevk@213.236.208.22)
  178. # [13:22] * Joins: timeless (timeless@65.75.195.122)
  179. # [15:56] * Joins: ChrisL (ChrisL@128.30.52.30)
  180. # [15:58] * Joins: glazou (glazou@80.118.184.70)
  181. # [15:58] * Parts: glazou (glazou@80.118.184.70)
  182. # [16:06] * Joins: fantasai (fantasai@71.138.141.152)
  183. # [16:35] * Joins: sylvaing (sylvaing@98.247.143.102)
  184. # [17:29] * Quits: ChrisL (ChrisL@128.30.52.30) (Client exited)
  185. # [17:45] * Quits: sylvaing (sylvaing@98.247.143.102) (Ping timeout)
  186. # [18:16] * Quits: arronei (arronei@131.107.0.80) (Ping timeout)
  187. # [18:22] * Joins: arronei (arronei@131.107.0.80)
  188. # [19:15] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  189. # [19:16] * Parts: anne (annevk@213.236.208.22)
  190. # [19:44] * Quits: fantasai (fantasai@71.138.141.152) (Quit: leaving)
  191. # [19:44] * Joins: fantasai (fantasai@71.138.141.152)
  192. # [21:15] * Joins: anne (annevk@85.196.122.246)
  193. # [21:43] * Joins: Lachy (Lachlan@85.196.122.246)
  194. # Session Close: Sat Feb 14 00:00:01 2009

The end :)