/irc-logs / w3c / #fx / 2012-02-21 / end

Options:

  1. # Session Start: Tue Feb 21 00:00:01 2012
  2. # Session Ident: #fx
  3. # [01:32] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  4. # [01:33] * Joins: cabanier (IceChat77@192.150.22.150)
  5. # [02:31] * Joins: krit (Adium@24.6.231.253)
  6. # [02:46] * Zakim excuses himself; his presence no longer seems to be needed
  7. # [02:46] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  8. # [02:54] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  9. # [02:55] * Joins: cabanier (IceChat77@192.150.22.150)
  10. # [03:11] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
  11. # [03:43] * Joins: shepazu (shepazu@128.30.52.169)
  12. # [04:08] * Quits: krit (Adium@24.6.231.253) (Quit: Leaving.)
  13. # [04:35] * Joins: krit (Adium@24.6.231.253)
  14. # [04:35] * Quits: krit (Adium@24.6.231.253) (Quit: Leaving.)
  15. # [04:35] * Joins: krit (Adium@24.6.231.253)
  16. # [05:15] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  17. # [05:16] * Joins: cabanier (IceChat77@192.150.22.150)
  18. # [05:43] * Quits: krit (Adium@24.6.231.253) (Quit: Leaving.)
  19. # [05:50] * Joins: krit (Adium@24.6.231.253)
  20. # [06:01] * Quits: krit (Adium@24.6.231.253) (Quit: Leaving.)
  21. # [08:49] * heycam is now known as heycam|away
  22. # [08:57] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  23. # [08:58] * Joins: cabanier (IceChat77@192.150.22.150)
  24. # [11:31] * RRSAgent excuses himself; his presence no longer seems to be needed
  25. # [11:31] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
  26. # [12:18] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  27. # [12:19] * Joins: cabanier (IceChat77@192.150.22.150)
  28. # [12:26] * heycam|away is now known as heycam
  29. # [12:50] * heycam is now known as heycam|away
  30. # [13:39] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  31. # [13:40] * Joins: cabanier (IceChat77@192.150.22.150)
  32. # [14:40] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  33. # [14:41] * Joins: cabanier (IceChat77@192.150.22.150)
  34. # [15:41] * Joins: krit (Adium@24.6.231.253)
  35. # [15:41] * Quits: shepazu (shepazu@128.30.52.169) (Client exited)
  36. # [15:41] * Joins: krit1 (Adium@24.6.231.253)
  37. # [15:43] * Quits: krit1 (Adium@24.6.231.253) (Quit: Leaving.)
  38. # [15:44] * Quits: krit (Adium@24.6.231.253) (Ping timeout)
  39. # [16:00] * Joins: shepazu (shepazu@128.30.52.169)
  40. # [16:00] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  41. # [16:02] * Joins: cabanier (IceChat77@192.150.22.150)
  42. # [17:42] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  43. # [17:43] * Joins: cabanier (IceChat77@192.150.22.150)
  44. # [17:59] * Joins: krit (Adium@192.150.10.201)
  45. # [18:29] <krit> oh cabanier!!! Welcome!
  46. # [18:29] <cabanier> :-)
  47. # [19:23] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  48. # [19:24] * Joins: cabanier (IceChat77@192.150.22.150)
  49. # [19:43] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  50. # [19:44] * Joins: cabanier (IceChat77@192.150.22.150)
  51. # [19:54] * Joins: dbaron (dbaron@159.63.23.38)
  52. # [20:03] * Quits: dbaron (dbaron@159.63.23.38) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  53. # [20:03] * Joins: dbaron (dbaron@159.63.23.38)
  54. # [20:21] * Joins: smfr (smfr@64.129.229.106)
  55. # [20:21] * Joins: AryehGregor (Aryeh@72.229.29.65)
  56. # [20:22] <smfr> bug list: https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Transforms&;resolution=---
  57. # [20:22] * Joins: dino (dino@64.129.229.106)
  58. # [20:23] <krit> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Transforms&;resolution=---
  59. # [20:25] <krit> * Get to CR as fast as possible?
  60. # [20:27] <krit> * Syntax changes? Should it get to CSS4 Transforms?
  61. # [20:27] <krit> * How to review changes on CSS3 Trnasforms?
  62. # [20:27] <krit> - If editors can't agree, ask CSS WG
  63. # [20:27] <krit> - Require review on changes of behavior
  64. # [20:28] * Quits: dbaron (dbaron@159.63.23.38) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  65. # [20:30] * Joins: dbaron (dbaron@159.63.23.38)
  66. # [20:30] <hober> ACTION: vhardy to ask MikeSmith to make sure all the editors are on the default CC list for our component
  67. # [20:30] * trackbot noticed an ACTION. Trying to create it.
  68. # [20:30] <trackbot> Created ACTION-71 - Ask MikeSmith to make sure all the editors are on the default CC list for our component [on Vincent Hardy - due 2012-02-28].
  69. # [20:31] <krit> - Add all editors to 'transform' bugs by default
  70. # [20:31] * Joins: vhardy_ (qw3birc@128.30.52.28)
  71. # [20:31] <hober> smfr is CCing everybody on the existing bugs
  72. # [20:32] <vhardy_> dean: what do we need to do to get the spec. to CR, which is what the community is asking. ... how do we handle changes to the current spec (e.g., rotate(angle, x, y)) ... we want to do the combination of CSS transform and SVG, which may be changes things slightly (e.g., discussions on units). =... then bugs. smfr: there is this issue of editorship. How do we review editor changes. We need to make sure there is agreement between editors. dirk: dean proposed to up
  73. # [20:32] <vhardy_> dean: what do we need to do to get the spec. to CR, which is what the community is asking.
  74. # [20:32] <vhardy_> ... how do we handle changes to the current spec (e.g., rotate(angle, x, y)) ... we
  75. # [20:32] <vhardy_> ... we want to do the combination of CSS transform and SVG, which may be changes things slightly (e.g., discussions on units).
  76. # [20:32] <vhardy_> ... then bugs.
  77. # [20:32] <vhardy_> smfr: there is this issue of editorship. How do we review editor changes. We need to make sure there is agreement between editors.
  78. # [20:33] <vhardy_> dirk: dean proposed to upload a patch to Bugzilla.
  79. # [20:33] <vhardy_> ted: yes, but nothing heavier.
  80. # [20:33] <vhardy_> dean: editorial is ok, does not need review.
  81. # [20:33] <vhardy_> ... anything that is a behavior change, should have a review.
  82. # [20:33] <vhardy_> ... if there is a situation where most implementations do one thing and one impl differs, then we should discuss it.
  83. # [20:34] <vhardy_> smfr: we may need conformance classes in the merged spec.
  84. # [20:34] <vhardy_> ... it should be possible for an impl to be compliant to the 2D transform part of the spec. and probably treat the 3D functions as invalid
  85. # [20:34] <vhardy_> dirk: may be could require a flattening of the transform?
  86. # [20:34] <vhardy_> smfr: probably not, because that gives weird results.
  87. # [20:35] <vhardy_> ... adding this conformance class would require edits.
  88. # [20:35] <vhardy_> ... someone needs to investiage conformance classes.
  89. # [20:35] <vhardy_> aryeh: the html5 spec. has conformance classes.
  90. # [20:36] <vhardy_> aryeh: css2.1 has conformance classes for print media I believe.
  91. # [20:36] <vhardy_> smfr: then, there must be special provisions in test cases.
  92. # [20:36] <vhardy_> aryeh: section 3.2 of CSS 2.1
  93. # [20:36] <dino> http://www.w3.org/TR/CSS2/conform.html
  94. # [20:36] <AryehGregor> http://www.w3.org/TR/CSS21/conform.html#conformance
  95. # [20:37] <vhardy_> vhardy: SVG also has classes of conformance (interactivity, animation, etc..)
  96. # [20:38] <vhardy_> dean: there will be 2D & HTML, 2D & HTML+SVG, 2D+3D & HTML, 2D+3D & HTML+SVG
  97. # [20:38] * shepazu is there a telcon going on?
  98. # [20:38] <smfr> shepazu: informal meeting of transform editors
  99. # [20:39] * shepazu cool, glad to hear it
  100. # [20:39] <vhardy_> dean: we need to get to the point, in WebKit, where we can do 3D transforms on SVG as well.
  101. # [20:39] <vhardy_> ... conformance classes need discussion with the group.
  102. # [20:40] <vhardy_> smfr: the most urgent conformance class is CSS+2D transform.
  103. # [20:40] <vhardy_> dean: the important thing is to go to CR and we can do it with conformance criteria.
  104. # [20:41] <vhardy_> ... we need to stabilize the syntax and drop the prefix.
  105. # [20:41] <vhardy_> dirk: I think we can do it with the SVG issues resolved.
  106. # [20:41] <vhardy_> ... the things that can affect CSS and HTML are already in the spec.
  107. # [20:42] <vhardy_> dean: so we would not allow an CSS trnasfomr for have unitless values.
  108. # [20:42] <vhardy_> dirk: right.
  109. # [20:42] <vhardy_> discussion about rotate(angle, cx, cy)
  110. # [20:42] <dino> AryehGregor, do you have opinions on the conformance?
  111. # [20:43] <AryehGregor> dino, what about the conformance?
  112. # [20:43] <AryehGregor> I'm primarily interested in mainstream web browsers, which will presumably aim to implement the whole thing, so I don't have strong feelings on other conformance classes.
  113. # [20:44] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  114. # [20:45] <vhardy_> Agreement among the editors to propose to the group to move the merged spec. along and add conformance levels to allow the spec. to move to CR.
  115. # [20:46] * Joins: cabanier (IceChat77@192.150.22.150)
  116. # [20:46] <vhardy_> ted: let's try to get the spec. CR ready and let the group decide how to proceed.
  117. # [20:46] <vhardy_> dirk: anything on the 2D part that requires our attention.
  118. # [20:49] <vhardy_> aryeh: there are things on the OM that we could address in the spec. The CSSMatrix and the CSSTransformValue do not need to be in the spec.
  119. # [20:49] <vhardy_> smfr: your bug will add wording about getBoundingClientRect. We also need to talk about hit testing on transform element and talk about elementFromPoint.
  120. # [20:50] <hober> elementFromPoint is defined in CSSOM View: http://dvcs.w3.org/hg/cssom-view/raw-file/tip/Overview.html#dom-document-elementfrompoint
  121. # [20:51] <vhardy_> Agreement: the next working draft should address the impact of CSS transforms on the existing CSS OM, but will not add any new CSSOM APIs which will be moved to Level 4
  122. # [20:51] <krit> http://dev.w3.org/csswg/css3-transforms/#transform-origin-property
  123. # [20:51] <vhardy_> dirk: in the last paragraph, there are 3 or 4 arguments for the property. I tried it yesterday and could not get it to work on Safari.
  124. # [20:52] <vhardy_> smfr: WebKit does not support the latest syntax. Sometimes in the back, dbaron asked to match background-position. WebKit does not support the latest background-position syntax.
  125. # [20:52] <vhardy_> ... for 3D, we added a new parameter (z-offer) which adds an ambiguity in the syntax.
  126. # [20:53] <vhardy_> aryeh: in my testing, no browser supports the background-position syntax. They support the 3D transform syntax.
  127. # [20:53] <vhardy_> smfr: webkit supports an eariler version of the background-position syntax.
  128. # [20:53] <vhardy_> ... we tried to keep the same parsing.
  129. # [20:53] <vhardy_> ... following the existing behavior would be limiting because it would difer from the background-positiong syntax.
  130. # [20:54] <dbaron> there's a teleconference now?
  131. # [20:54] <vhardy_> dirk: why do we need to follow the same syntax?
  132. # [20:54] <vhardy_> smfr: because authors only need to remember one syntax.
  133. # [20:54] <dino> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15432 3D syntax for transform-origin conflicts with background-position-like syntax, causing ambiguity
  134. # [20:54] <AryehGregor> dbaron, yes.
  135. # [20:54] <vhardy_> ... they essentially specify somehting similar.
  136. # [20:54] <AryehGregor> Not the whole TF.
  137. # [20:54] <vhardy_> smfr: prefix have been dropped on background-position.
  138. # [20:54] <vhardy_> ... the syntax is in Background and Borders.
  139. # [20:55] <vhardy_> ... published a week ago.
  140. # [20:55] <vhardy_> dirk: current implementations do not support the new syntax.
  141. # [20:55] <vhardy_> smfr: we need to add some syntax to lift ambiguity with 3D transforms.
  142. # [20:56] <vhardy_> dean: we would put a slash between the 2D and the 3D parts of the transform-origin. the 2D part would match the background-poisition syntax.
  143. # [20:56] <vhardy_> ... the other option would be to have a transform-origin-z property and then transform-origin could have the exact same syntax as bacgkround-position.
  144. # [20:57] <vhardy_> aryeh: does any browser implement the new syntax/
  145. # [20:57] <vhardy_> (not WebKit not FF).
  146. # [20:57] <vhardy_> aryeh: could achieve the same thing with the old syntax and calc()
  147. # [20:57] <vhardy_> smfr: I do not think we support enought of calc()
  148. # [20:58] <vhardy_> vhardy: I like the idea of a transfomr-origin-z property.
  149. # [20:58] <vhardy_> smfr: then, people may ask for a shorthand that includes the transform-origin property.
  150. # [20:58] <vhardy_> ... may be bring that to the list?
  151. # [20:58] <vhardy_> aryeh: yes, that is a good idea.
  152. # [20:59] <vhardy_> dirk: what is the best option? I like the new property too.
  153. # [20:59] <vhardy_> smfr: me too.
  154. # [20:59] <vhardy_> ted: I am ambivalent, but sure.
  155. # [21:00] <vhardy_> aryeh: I think it is fine to keep the old syntax.
  156. # [21:00] <vhardy_> dean: it is true that calc() will help a lot and resolve that issue.
  157. # [21:02] <vhardy_> disagreeemnt on whether or not the syntax of transform-origin should align with background-position.
  158. # [21:02] <vhardy_> ACTION: Aryeh to send email to www-style about aligning the transform-origin syntax with background-position (or not) and present the pros and cons for each.
  159. # [21:02] * trackbot noticed an ACTION. Trying to create it.
  160. # [21:02] <trackbot> Sorry, couldn't find user - Aryeh
  161. # [21:03] <vhardy_> ACTION: AryehGregor to send email to www-style about aligning the transform-origin syntax with background-position (or not) and present the pros and cons for each.
  162. # [21:03] * trackbot noticed an ACTION. Trying to create it.
  163. # [21:03] <trackbot> Sorry, couldn't find user - AryehGregor
  164. # [21:03] * hober :(
  165. # [21:03] <vhardy_> https://www.w3.org/Style/CSS/Tracker/users/43808
  166. # [21:04] <vhardy_> ACTION: agregor to send email to www-style about aligning the transform-origin syntax with background-position (or not) and present the pros and cons for each.
  167. # [21:04] * trackbot noticed an ACTION. Trying to create it.
  168. # [21:04] <trackbot> Sorry, couldn't find user - agregor
  169. # [21:04] <dino> trackbot, info?
  170. # [21:04] <trackbot> Sorry, dino, I don't understand 'trackbot, info?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
  171. # [21:04] <dino> trackbot, status
  172. # [21:04] * trackbot knows about the following 23 users: Dirk, Jonathan, Doug, Elika, Brian, Edward, Peter, Daniel, Steve, Cyril, Robin, Patrick, Jennifer, David, Tab, Cameron, Brad, Chris, David, Vincent, Erik, Dean, Simon
  173. # [21:04] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  174. # [21:04] <vhardy_> ACTION: 43808 to send email to www-style about aligning the transform-origin syntax with background-position (or not) and present the pros and cons for each.
  175. # [21:04] * trackbot noticed an ACTION. Trying to create it.
  176. # [21:04] <trackbot> Sorry, couldn't find user - 43808
  177. # [21:06] <vhardy_> dirk: computed value
  178. # [21:06] * hober these logs are at http://log.csswg.org/irc.w3.org/fx/?date=2012-02-21
  179. # [21:06] * Joins: cabanier (IceChat77@192.150.22.150)
  180. # [21:06] <vhardy_> ... at the moment it is specified to use matrix and matrix3D
  181. # [21:07] <vhardy_> aryeh: now, all browsers return unitless matrix() values
  182. # [21:07] <vhardy_> dirk: do we need to return a matrix or the transformation list?
  183. # [21:07] <vhardy_> smfr: it is more useful to return the transformation list.
  184. # [21:08] <vhardy_> dirk: I think it is most useful.
  185. # [21:08] <vhardy_> aryeh: every single property returns a value that can be used as a property value.
  186. # [21:08] <vhardy_> dirk: I think we should return matrix() and matrix3d() but in the future, the CSS OM will return the transformation list.
  187. # [21:09] <vhardy_> smfr: we cannot change that decision in the future though.
  188. # [21:09] <vhardy_> ... we can wait for the CSS OM changes, but I do not think that getComputedStyle is going to go away any time soon.
  189. # [21:10] <vhardy_> ... and while animations are running, it is not clear that you would get the proper value.
  190. # [21:10] <vhardy_> ... we could also say it is not specified, and say it could be a matrix or a list of transforms.
  191. # [21:10] <vhardy_> dirk: we could say the browsers should return a transformation list, but may return a matrix() or matrix3d()
  192. # [21:11] <vhardy_> smfr: CSS specs. have not specified the getComputedStyle behavior much anyway.
  193. # [21:14] <vhardy_> dirk: for animation, since we decompose and recompose, we have to return a matrix()
  194. # [21:16] <vhardy_> dean: this may content tests, but I doubt this will break content.
  195. # [21:17] <vhardy_> dean: I think returning the transformation list is the right thing to do.
  196. # [21:17] <vhardy_> dean: I would expect the lengths would get resolved to 'px' in the returned value.
  197. # [21:20] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15431
  198. # [21:20] <dino> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15797
  199. # [21:20] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15797
  200. # [21:22] <vhardy_> Agreement: the transform value returned from getComputedStyle should be a transform list, with lengths resolved in px units, with the exception of animated transform values which may use matrix() in case the list of transform functions does not match.
  201. # [21:23] <vhardy_> dirk: do we need a statement about the computed values for the other properties (such as transform-origin)?
  202. # [21:23] <vhardy_> ted: I do not think we need to say more here.
  203. # [21:24] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15433
  204. # [21:24] <vhardy_> smfr: we should do the same for transform-origin as background-position.
  205. # [21:25] <vhardy_> ... transformStyle is simple.
  206. # [21:26] <vhardy_> smfr: perspectiveOrigin should also match background-position.
  207. # [21:26] <vhardy_> s/perspectiveOrigin/perspective-origin
  208. # [21:26] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15681
  209. # [21:27] <vhardy_> smfr: adding a bug to Bugzilla to align perspective-origin with background-position.
  210. # [21:28] <smfr> I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16064
  211. # [21:29] * Quits: krit (Adium@192.150.10.201) (Quit: Leaving.)
  212. # [21:30] * Joins: krit (Adium@192.150.10.201)
  213. # [21:31] * Quits: krit (Adium@192.150.10.201) (Quit: Leaving.)
  214. # [21:32] * Quits: vhardy_ (qw3birc@128.30.52.28) (Ping timeout)
  215. # [21:32] * Quits: dino (dino@64.129.229.106) (Quit: dino)
  216. # [21:32] * Quits: smfr (smfr@64.129.229.106) (Quit: smfr)
  217. # [21:45] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  218. # [21:46] * Joins: cabanier (IceChat77@192.150.22.150)
  219. # [22:27] * Quits: cabanier (IceChat77@192.150.22.150) (Quit: Make it idiot proof and someone will make a better idiot.)
  220. # [22:27] * Joins: cabanier (IceChat77@66.220.98.66)
  221. # [22:28] * Quits: cabanier (IceChat77@66.220.98.66) (Quit: IceChat - Its what Cool People use)
  222. # [22:28] * Joins: cabanier (IceChat77@192.150.22.150)
  223. # [22:51] * Joins: krit (Adium@192.150.10.201)
  224. # [22:54] <krit> Use transform list instead of anything else.
  225. # [22:54] <krit> and transformation functions for the single operations
  226. # [22:54] * Joins: smfr (smfr@64.129.229.106)
  227. # [22:56] <krit> smfr: No benefit to have transform-orign a list
  228. # [22:57] <krit> smfr: doesn't follow the way how mutliple backgrounds work
  229. # [22:57] <krit> smfr: argue against trasform-orign with multple arguments
  230. # [22:58] <krit> krit: grouping transformation functions would be against syntax of SVG transform
  231. # [22:59] <krit> krit: rotate with three agruments for backward comp. to SVG Transforms
  232. # [23:00] <krit> smfr: rotate with 3 arguments might need to change rotate3d as well
  233. # [23:01] <krit> krit: if you implement rotae just for svg, you would end up with implementing it for SVG
  234. # [23:01] <hober> hober: we could add it in level 4
  235. # [23:01] <krit> s/SVG/HTML
  236. # [23:01] <krit> krit: optional for HTML?
  237. # [23:01] <krit> smfr: might be ok
  238. # [23:02] <krit> smfr: remove it form 2D transformation functions and add it to SVG. making it optional for HTML
  239. # [23:03] <krit> krit: and scale?
  240. # [23:03] <krit> smfr: no
  241. # [23:03] <krit> krit: to intersection issues to 3D
  242. # [23:03] <krit> http://lists.w3.org/Archives/Public/www-style/2012Feb/0911.html
  243. # [23:04] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15784
  244. # [23:05] <krit> krit: make it clear how intersection works for all UAs
  245. # [23:05] <krit> smfr: should be discussed on CSS WG
  246. # [23:05] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  247. # [23:05] <krit> smfr: if AryehGregor agrees if two implementations implement it than it is fine
  248. # [23:06] <krit> smfr: if Mozilla implements it
  249. # [23:06] <krit> smfr: if we put it in the spec, how do we describe it?
  250. # [23:07] <krit> smfr: it would be good if AryehGregor agrees to make in normative. If he is ok, we can leave it in the spec ant say there is an issue or waiting for feedback
  251. # [23:07] <krit> smfr: need more math spec? who can desrcibe that? Would be a lot of math
  252. # [23:07] * Joins: cabanier (IceChat77@192.150.22.150)
  253. # [23:08] <krit> krit: background an transform
  254. # [23:08] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15432\]
  255. # [23:08] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15432
  256. # [23:08] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15833
  257. # [23:08] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15834
  258. # [23:09] <krit> smfr: first bug: new property translate-prigin-z or slash and 3d arguments
  259. # [23:10] <krit> smfr: fixed background, bg should stay the same on 2d transform independent of the transf. element
  260. # [23:10] <krit> smfr: not sure about 3d transforms
  261. # [23:11] <krit> smfr: WG should discuss it
  262. # [23:11] <krit> smfr: maybe others have good ideas
  263. # [23:11] <krit> s/others/AryehGregor/
  264. # [23:12] <krit> smfr: AryehGregor is reasonable for 2d on https://www.w3.org/Bugs/Public/show_bug.cgi?id=15833
  265. # [23:12] <krit> smfr: hober: not for 3d
  266. # [23:12] <krit> smfr: don't want different behavior on 2d or 3d
  267. # [23:15] <krit> smfr: hober: undefined for 3D and 2d or make is static
  268. # [23:17] <krit> krit: don't like undefined
  269. # [23:17] <krit> smfr: it is a edge case
  270. # [23:17] <krit> smfr: what about fixed position on elements
  271. # [23:18] <krit> smfr: simiilar kind of problem
  272. # [23:22] * heycam|away is now known as heycam
  273. # [23:25] <krit> smfr: need input for other implemenrters: exempls
  274. # [23:25] <krit> e
  275. # [23:26] <krit> <div style="position: absolute…"><div style="position: fixed"></div></div> now you transform the first div
  276. # [23:26] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  277. # [23:26] <krit> smfr: should fixed object get transformed as well?
  278. # [23:26] <krit> krit: I think yes, because you transform the coordinate system, not the element
  279. # [23:27] * heycam wonders if this is an ad hoc FX meeting? or an offshoot of CSS meeting?
  280. # [23:27] <krit> krit: and the viewport stays the same, but in another coordinate system
  281. # [23:27] * Joins: cabanier (IceChat77@192.150.22.150)
  282. # [23:27] <krit> smfr: It should be independent of the parent div
  283. # [23:28] <krit> smfr: and just rely to the viewport, not to the transformation of the parent
  284. # [23:28] <smfr> heycam: an informal css transforms editors meeting
  285. # [23:28] * heycam smfr ok cool
  286. # [23:31] <krit> krit: what about the conflicts betweenn transform-origin/style and perspective
  287. # [23:31] <krit> [18] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15432
  288. # [23:31] <krit> [19] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15521
  289. # [23:31] <krit> [20] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15680
  290. # [23:31] <krit> [21] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15782
  291. # [23:31] <krit> [22] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15800
  292. # [23:31] <krit> [23] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15871
  293. # [23:31] <krit> [24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15943
  294. # [23:31] <krit> smfr: first resolved
  295. # [23:32] <krit> smfr: spec needs updated to take the same syntax for transform-origin and persp.-origin
  296. # [23:32] <krit> smfr: [10] resolve later
  297. # [23:33] <krit> smfr: [19] resolve later
  298. # [23:33] <krit> smfr: [21] edit spec
  299. # [23:34] <krit> krit: [22] I'll add an example to make it clear
  300. # [23:36] <krit> smfr: ask AryehGregor if he can check the mupltiplication of matrix stuff to make sure what 'postmultiply' means
  301. # [23:37] <krit> smfr: [23] agree with AryehGregor that webkits behavior is a bug
  302. # [23:38] <krit> smfr: [24] webkits bahvior probably jsut a bug
  303. # [23:38] <krit> smfr: we should avoid special casing
  304. # [23:39] * Quits: smfr (smfr@64.129.229.106) (Quit: smfr)
  305. # [23:40] <krit> krit: can AryehGregor get an editor?
  306. # [23:40] <krit> (genera agreement)
  307. # [23:40] * Quits: krit (Adium@192.150.10.201) (Quit: Leaving.)
  308. # [23:46] * Quits: cabanier (IceChat77@192.150.22.150) (Connection reset by peer)
  309. # [23:47] * Joins: cabanier (IceChat77@192.150.22.150)
  310. # [23:52] * Joins: krit (Adium@192.150.10.201)
  311. # Session Close: Wed Feb 22 00:00:00 2012

The end :)