/irc-logs / w3c / #css / 2009-07-15 / end

Options:

  1. # Session Start: Wed Jul 15 00:00:00 2009
  2. # Session Ident: #css
  3. # [00:23] * Quits: arronei (arronei@131.107.0.114) (Client exited)
  4. # [00:23] * Joins: arronei (arronei@131.107.0.112)
  5. # [02:19] * Quits: dbaron_ (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  6. # [03:01] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  7. # [03:39] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  8. # [03:39] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
  9. # [03:40] * Quits: billyjackass (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  10. # [03:40] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  11. # [03:41] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  12. # [04:11] * Quits: karl (karlcow@128.30.54.58) (Client exited)
  13. # [04:22] * Joins: karl (karlcow@128.30.54.58)
  14. # [05:59] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  15. # [06:02] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  16. # [10:21] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  17. # [10:22] * Joins: MoZ (chatzilla@134.225.30.177)
  18. # [10:24] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  19. # [12:40] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  20. # [13:40] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  21. # [13:42] * Joins: Lachy (Lachlan@85.196.122.246)
  22. # [14:22] * Joins: myakura (myakura@125.200.97.137)
  23. # [17:06] * Joins: glazou (glazou@80.118.184.70)
  24. # [17:08] * Quits: glazou (glazou@80.118.184.70) (Quit: glazou)
  25. # [17:27] * Joins: glazou (daniel@80.118.184.70)
  26. # [17:30] * Quits: glazou (daniel@80.118.184.70) (Quit: glazou)
  27. # [17:51] * Quits: myakura (myakura@125.200.97.137) (Quit: Leaving...)
  28. # [17:53] * Joins: dbaron (dbaron@63.245.220.240)
  29. # [17:57] * Joins: glazou (glazou@82.247.96.19)
  30. # [17:57] <glazou> hello
  31. # [17:58] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  32. # [17:58] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  33. # [17:58] <RRSAgent> logging to http://www.w3.org/2009/07/15-CSS-irc
  34. # [17:58] <glazou> Zakim, this is Style
  35. # [17:58] <Zakim> ok, glazou; that matches Style_CSS FP()12:00PM
  36. # [17:59] * Joins: hyatt (hyatt@98.201.21.231)
  37. # [18:00] * Joins: dino (dino@17.203.15.167)
  38. # [18:02] * Joins: cesar_acebal (acebal@85.152.176.161)
  39. # [18:02] <Zakim> + +1.858.216.aabb
  40. # [18:02] <plinss> zakim, +1.858.216 is me
  41. # [18:02] <Zakim> +plinss; got it
  42. # [18:03] <Zakim> + +1.281.419.aacc
  43. # [18:03] <hyatt> zakin, 1.281.419 is me
  44. # [18:03] <hyatt> zakim, 1.281.419 is me
  45. # [18:03] <Zakim> sorry, hyatt, I do not recognize a party named '1.281.419'
  46. # [18:04] <plinss> zakim, +1.281.419 is hyatt
  47. # [18:04] <Zakim> +hyatt; got it
  48. # [18:04] <Zakim> +[Microsoft]
  49. # [18:05] <Zakim> +[Mozilla]
  50. # [18:05] <dbaron> Zakim, [Mozilla] has dbaron
  51. # [18:05] * Joins: sgalineau (sylvaing@131.107.0.114)
  52. # [18:05] <Zakim> +dbaron; got it
  53. # [18:05] * Joins: ChrisL (ChrisL@128.30.52.30)
  54. # [18:06] * Quits: sgalineau (sylvaing@131.107.0.114) (Quit: sgalineau)
  55. # [18:06] <dbaron> Zakim, who is on the phone?
  56. # [18:06] <Zakim> On the phone I see +95089aaaa, plinss, hyatt, [Microsoft], [Mozilla]
  57. # [18:06] <Zakim> [Mozilla] has dbaron
  58. # [18:06] <Zakim> + +34.60.940.aadd
  59. # [18:06] * dino zakim, number?
  60. # [18:06] * Zakim I don't understand your question, dino.
  61. # [18:07] * Joins: sgalineau (sylvaing@131.107.0.114)
  62. # [18:07] <cesar_acebal> zakim, +34.60.940 is me
  63. # [18:07] <Zakim> +cesar_acebal; got it
  64. # [18:07] <sgalineau> Zakim, [Microsoft] has sylvaing
  65. # [18:07] <Zakim> +sylvaing; got it
  66. # [18:07] * dbaron to dino, 16177616200, 78953
  67. # [18:07] <Zakim> + +1.408.588.aaee
  68. # [18:07] <Zakim> +Bert
  69. # [18:07] <Zakim> + +39.524.9.aaff
  70. # [18:08] * dino dbaron - thanks
  71. # [18:08] <Zakim> +fantasai
  72. # [18:08] <ChrisL> zakim, +39 is me
  73. # [18:08] <Zakim> +ChrisL; got it
  74. # [18:08] <Zakim> -cesar_acebal
  75. # [18:08] * dino zakim, aaee is me
  76. # [18:08] * Zakim +dino; got it
  77. # [18:08] <dbaron> Zakim, who is on the phone?
  78. # [18:08] <Zakim> On the phone I see +95089aaaa, plinss, hyatt, [Microsoft], [Mozilla], dino, Bert, ChrisL, fantasai
  79. # [18:08] <Zakim> [Mozilla] has dbaron
  80. # [18:08] <Zakim> [Microsoft] has sylvaing
  81. # [18:08] <Zakim> + +1.650.766.aagg
  82. # [18:08] * dbaron wonders who the first person on the call was
  83. # [18:08] <ChrisL> zaki, where is +95?
  84. # [18:09] <ChrisL> zakim, where is +95?
  85. # [18:09] <Zakim> country code 95 is Burma (Myanmar)
  86. # [18:09] <Zakim> +cesar_acebal
  87. # [18:09] * ChrisL mind you it got my country code wrong, so ....
  88. # [18:09] * Joins: szilles (chatzilla@71.202.66.40)
  89. # [18:09] * dbaron notes wikipedia agrees: http://en.wikipedia.org/wiki/List_of_country_calling_codes#Zone_9_.E2.80.93_West.2C_South_and_Central_Asia
  90. # [18:10] * ChrisL points out it thinks I am calling from +39 instead of +33 9 ....
  91. # [18:10] * ChrisL decides to be bold (in the wikipedia sense)
  92. # [18:10] <Zakim> +SteveZ
  93. # [18:11] <ChrisL> zakim, drop +95
  94. # [18:11] <Zakim> +95089aaaa is being disconnected
  95. # [18:11] <Zakim> - +95089aaaa
  96. # [18:11] <sgalineau> scribenick: sylvaing
  97. # [18:11] * glazou just lost phone
  98. # [18:11] * ChrisL sorry glazou
  99. # [18:11] * ChrisL please redial
  100. # [18:11] <glazou> yep
  101. # [18:12] <Zakim> + +95089aahh
  102. # [18:12] <glazou> glad to see you too ChrisL :)
  103. # [18:12] <dbaron> Zakim, aahh is glazou
  104. # [18:12] <Zakim> +glazou; got it
  105. # [18:12] <sgalineau> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0006.html
  106. # [18:12] <sgalineau> Gabriele Romanato as invited expert ?
  107. # [18:13] * ChrisL http://gabrieleromanato.altervista.org/
  108. # [18:16] * ChrisL http://www.flickr.com/people/gabrieleromanato/
  109. # [18:17] <sgalineau> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0003.html
  110. # [18:18] <dbaron> Zakim, who is noisy?
  111. # [18:18] <Zakim> dbaron, listening for 10 seconds I heard sound from the following: 12 (65%), glazou (5%), fantasai (15%)
  112. # [18:18] <sgalineau> hyatt describes his HTML5 datagrid request
  113. # [18:18] <dbaron> Zakim, who is on the phone?
  114. # [18:18] <Zakim> On the phone I see plinss, hyatt, [Microsoft], [Mozilla], dino, Bert, ChrisL, fantasai, +1.650.766.aagg, cesar_acebal, SteveZ, glazou
  115. # [18:18] <Zakim> [Mozilla] has dbaron
  116. # [18:18] <Zakim> [Microsoft] has sylvaing
  117. # [18:18] <sgalineau> fantasai: i don't think the wg is against it, but do we have enough to work on it ?
  118. # [18:19] <sgalineau> hyatt: we don't need a module since we don't know exactly what to put in yet but it should be on the wg's radar screen
  119. # [18:20] <sgalineau> hyatt: i'm prepared to champion it but I want to fix the HTML spec first
  120. # [18:20] * dbaron hasn't looked at the HTML5 datagrid
  121. # [18:20] <sgalineau> fantasai: I think we consider it to be in scope but the issue now is resources
  122. # [18:20] <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html
  123. # [18:21] <sgalineau> Issue 128: display:run-in clarifications
  124. # [18:22] <sgalineau> hyatt: I agree with Boris' proposed solution for run-in issues
  125. # [18:22] <sgalineau> fantasai: we need more details for the spec though
  126. # [18:22] <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jun/0121.html
  127. # [18:22] <sgalineau> (Moving to transitions since hyatt and dean are present)
  128. # [18:22] <glazou> jdaggett: ping
  129. # [18:23] * sgalineau scribe is ahead of the chair. doh.
  130. # [18:23] <sgalineau> [css3-transitions] suppression of transition starting, inheritance
  131. # [18:24] <sgalineau> dbaron: I don't have a useful proposal for this nor have i seen a solution that i like
  132. # [18:24] <sgalineau> dbaron describes webkit implementation
  133. # [18:25] <sgalineau> chrisl: do you expect the transitions to run in parallel ?
  134. # [18:25] <sgalineau> dbaron: not sure
  135. # [18:25] <sgalineau> hyatt: that's what I expect.
  136. # [18:25] <ChrisL> i would expect them to run in parallel, yes
  137. # [18:26] <sgalineau> dbaron: the hard question is what if one of the descendants also has a different transition on the inherited propery
  138. # [18:27] <sgalineau> chrisl: SMIL addressed this.
  139. # [18:27] <sgalineau> dean: SMIL does not have the concept of a computed style.
  140. # [18:28] <sgalineau> hyatt: not sure webkit is running transitions are running sequentially. inner transitions keep restarting as the outer one is inherited
  141. # [18:29] <sgalineau> hyatt: do we want to special-case the inheritance of an animated value ?
  142. # [18:30] <sgalineau> dean: currently we don't know whether the value changes due to animation or inheritance
  143. # [18:30] * fantasai sgalineau, want some help?
  144. # [18:30] * sgalineau fantasai, sure :)
  145. # [18:30] <fantasai> dean: ... behavior can be helpful at times ... you don't want to have to turn transitions off to start the drag
  146. # [18:30] <fantasai> dean: wnat to quickly reset transitions in work
  147. # [18:31] * sgalineau such a nice way to tell me I need some...
  148. # [18:31] <fantasai> dbaron: I don't quite understand the dragging example
  149. # [18:31] <fantasai> dean: What our impl doing incorrectly.. in hte inner value with the inherited color value
  150. # [18:31] <fantasai> dean: you're getting zillions of transitions starting one for every step of the parent
  151. # [18:31] <fantasai> dean: ... child says now I can run to completion
  152. # [18:31] <fantasai> dean: that's what happens when you're interactively moving things around
  153. # [18:32] <fantasai> dean: say you move something w/ mouse 10px and it starts a transition
  154. # [18:32] <fantasai> dean: it starts a transition every millisecond
  155. # [18:32] <sgalineau> Zakim, [Microsoft] has arronei,alexmog
  156. # [18:32] <Zakim> +arronei, alexmog; got it
  157. # [18:32] <fantasai> dbaron: what do you mean it restarts the transition every time the outer transition kicks forward
  158. # [18:32] <fantasai> dbaron: how does it end up so that it's running the transition of the child when the .... all thte way at the beginning value
  159. # [18:32] <fantasai> hyatt: You always transition where you are
  160. # [18:33] <fantasai> hyatt: it starts inheriting the animated values, and it thinks its transitioning from start to the value
  161. # [18:33] <fantasai> hyatt: it's never really getting a chance to move 'cuz it transitions over and over again
  162. # [18:33] <fantasai> hyatt: when the outer elmeent ends its transition, you have to start almost from the beginning
  163. # [18:33] <fantasai> hyatt: when you change the outer element, it's resetting and triggering a transition on the inner element over and over
  164. # [18:34] <fantasai> dbaron: we don't want to initiate transitions from changes that initiate from other sources
  165. # [18:34] <fantasai> dbaron: e.g. if there's a SMILE element moving something gradually and there's a transition in there, we suppress the transition there
  166. # [18:34] <fantasai> hyatt: you mean you can't do nested transitions?
  167. # [18:34] <fantasai> hyatt: that doesn't actually bother me... I don't think this behavior is what you'd want even remotely
  168. # [18:34] <fantasai> hyatt: so I'd be fine with that.
  169. # [18:34] <fantasai> dbaron: Well there's cases where it breaks things that you want
  170. # [18:35] <fantasai> dbaron: if we say we ignore the nested transition, then if you have a 5s transition on the color property and a 100ms transition on the ancestor
  171. # [18:35] <fantasai> dbaron: you have discontinuity between no transition and really short transition (/)
  172. # [18:35] <fantasai> hyatt: is the second one inheriting its color from the outer?
  173. # [18:36] <fantasai> dbaron: yes. But if you suppress the color transition then the inner one transitions too fast
  174. # [18:36] <fantasai> hyatt: then suppress the transition only while the outer one is running
  175. # [18:36] <fantasai> dbaron: my impl does that [but it's weird]
  176. # [18:37] <glazou> what's that bzzzzzzz loud sound ?
  177. # [18:37] <fantasai> hyatt: ... the inner element ... should just start its own transition
  178. # [18:37] * Joins: alexmog (alexmog@131.107.0.75)
  179. # [18:37] <fantasai> hyatt: you should include the end value in that and not do the 5s animation after the 100ms one
  180. # [18:38] * alexmog blames traffic
  181. # [18:38] <sgalineau> would it help if inner elements only saw/inherited the end value of the parent's transition ?
  182. # [18:38] <fantasai> ?: I think what you're saying is while the outer transition is running the inner one is not affected
  183. # [18:38] <fantasai> ...
  184. # [18:38] <fantasai> dean: spec says once you start a transition the transition value are locked
  185. # [18:39] <fantasai> dean: if you poke the inner one then you aren't inheriting anymore
  186. # [18:39] <fantasai> ...
  187. # [18:39] <fantasai> dbaron: I think that seems reasonable enough
  188. # [18:39] <fantasai> dbaron: in that it's better than anything else we've thought of
  189. # [18:39] <fantasai> dbaron, can you please type the summary?
  190. # [18:39] * fantasai lost a few lines there
  191. # [18:40] * fantasai has also lost microphone
  192. # [18:40] <fantasai> everyone seems to agree on the agreement, which hopefully will be typed in the minutes shortly :)
  193. # [18:40] <dbaron> tentative resolution is that something inheriting a transitioning value (including at the start of the transition) doesn't start its own transitions
  194. # [18:41] <dbaron> and that dean will put something about it in the spec
  195. # [18:41] <sgalineau> hyatt: if you inherit a currently animating value you won't run a transition until that transition is complete ?
  196. # [18:41] <fantasai> hyatt: basically what you're saying is if you inherit a currently-animating value, you won't transition on the animating value
  197. # [18:41] <dbaron> (yeah, transitioning value or animating due to other animations)
  198. # [18:41] <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jun/0338.html
  199. # [18:41] <sgalineau> [css3-transitions] animation of shadows
  200. # [18:42] <fantasai> transparent
  201. # [18:42] <fantasai> we never use currentColor in shadows
  202. # [18:42] <fantasai> the default color is UA-defined, usually some variant of gray or black
  203. # [18:43] <fantasai> chris suggests padding with a shadow of zero offsets and black
  204. # [18:43] <ChrisL> suggest a default 0 0 0 0 rgba(0,0,0,0)
  205. # [18:43] <ChrisL> so transparent black
  206. # [18:43] <ChrisL> s/and black/and transparent black/
  207. # [18:43] <fantasai> dean: Someone asked a question about animating colors through different color spaces
  208. # [18:44] <fantasai> dean: We did some experiments, and we all thought that it would be better to animate through hsl
  209. # [18:44] <fantasai> dean: when you animate through rgb you sometimes wind up with a sort of gray color
  210. # [18:44] <fantasai> chrisl: it should give you better results
  211. # [18:44] <fantasai> chrisl: can have a property to choose
  212. # [18:45] <fantasai> dean: we didn't think it was necessary, hsl just usually gives better results
  213. # [18:45] <dbaron> dean: animating in hsl() space sometimes look really wrong; animating in rgb() space generally looks reasonable, although sometimes dull
  214. # [18:46] <dbaron> Zakim, who is on the phone?
  215. # [18:46] <Zakim> On the phone I see plinss, hyatt, [Microsoft], [Mozilla], dino, Bert, ChrisL, fantasai, +1.650.766.aagg, cesar_acebal, SteveZ, glazou
  216. # [18:46] * Quits: MoZ (chatzilla@134.225.30.177) (Ping timeout)
  217. # [18:46] <Zakim> [Mozilla] has dbaron
  218. # [18:46] <Zakim> [Microsoft] has arronei, alexmog
  219. # [18:46] <dbaron> Zakim, aagg is Brad_Kemper
  220. # [18:46] <Zakim> +Brad_Kemper; got it
  221. # [18:46] <Bert> About transitions and inheritance, maybe something like: "A change in a property's value only triggers a transition if the new value is due to the cascade, not if it is due to inheritance."?
  222. # [18:46] * fantasai missed all that
  223. # [18:46] * glazou did not hear Brad
  224. # [18:46] * fantasai should hand back over to sgalineau
  225. # [18:46] <fantasai> :)
  226. # [18:47] * fantasai does not have a microphone! can someone summarize the comment I missed?
  227. # [18:47] <fantasai> hyatt: Issue 7 and 8 are related
  228. # [18:47] <fantasai> hyatt: can we change the spec to say it applies to all elements
  229. # [18:47] * fantasai what is "it"?
  230. # [18:48] * fantasai needs a resolution on the color space recommendation
  231. # [18:48] * sgalineau animation applies to all elements ?
  232. # [18:48] <dbaron> Bert, I don't think we want that
  233. # [18:48] <hyatt> for shadows, pad the shorter list with 0 0 0 0 rgba(0,0,0,0.0)
  234. # [18:48] <fantasai> plinss: can you ask for a formal resolution on these issues, one by one?
  235. # [18:48] <dbaron> Bert, although I suppose it's possible
  236. # [18:49] <fantasai> Brad?: You're saying that you setting the default shadow .. are you also going to default blur radius and offset?
  237. # [18:49] <fantasai> hyatt: yeah, to zero
  238. # [18:49] <ChrisL> yes, that was my suggestion, 0 0 0 0
  239. # [18:50] <fantasai> chrisl: i think it's a good default, and if people want something else they can ask for it explicitly
  240. # [18:50] <fantasai> RESOLVED: default shadow is 0 0 0 0 rgba(0, 0, 0, 0.0) for transitions where the shadows don't match
  241. # [18:51] <fantasai> in #of shadows
  242. # [18:52] <fantasai> dean: I believe we also had a resolution that transition properties apply to all elements (?)
  243. # [18:52] <fantasai> Any objections or is this resolved?
  244. # [18:52] <fantasai> *pokes the chair*
  245. # [18:52] <sgalineau> RESOLVED: transitions apply to all elements, not just block and inline re: http://lists.w3.org/Archives/Public/www-style/2009Jun/0479.html
  246. # [18:52] <fantasai> hyatt: Webkit doesn't run transitions on pseudoelements at all
  247. # [18:52] <fantasai> hyatt: And we don't do it for inherited :first-line styles either
  248. # [18:53] <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jun/0478.html
  249. # [18:53] <fantasai> hyatt: I'm not convinced it's what we should do, but our implementation dodges those questions
  250. # [18:53] <fantasai> hyatt: It seems reasonable to run transitions on certain pseudo-elements. :first-line is trickier because the same object has multiple styles
  251. # [18:53] <fantasai> dbaron: We might want to restrict the spec to tree-like pseudo-elements
  252. # [18:54] <fantasai> dbaron: e.g. apply to :before/:after, but not :first-line
  253. # [18:54] <fantasai> hyatt: I say you wouldn't transition on styles resulting from :first-line etc.
  254. # [18:54] <fantasai> ...
  255. # [18:55] <fantasai> dbaron: The problem with :first-line is that you can have an element that is partly in the first line and partly out of it
  256. # [18:55] <fantasai> dbaron: e.g. a span,
  257. # [18:55] <fantasai> dbaron: the span there has two different colors
  258. # [18:55] <fantasai> dbaron: If the span has a transition color, and you set a transition on the paragraph
  259. # [18:55] <fantasai> dbaron: what transitions?
  260. # [18:56] <fantasai> hyatt: in the webkit impl the first-line style will just snap, and the transition runs on everything else
  261. # [18:56] <fantasai> dbaron: Bert said something interesting on IRC 10 min ago
  262. # [18:56] <fantasai> dbaron: he suggested transitions should only be triggered on non-inherited values
  263. # [18:56] <fantasai> hyatt: you could make a case for e.g. user hits cmd+ to increase font-size and you want that to transition
  264. # [18:57] <fantasai> dbaron: it would make this issue disappear
  265. # [18:57] <fantasai> dbaron: :first-letter, :first-line, and ::selection can all span multiple elements
  266. # [18:57] <fantasai> hyatt: I am totally fine with a first cut of this saying it doesn't apply to pseudo-elements at all
  267. # [18:58] <fantasai> dbaron: from impl experience the next piece of code I was going to write was te redo this bit, so I don't have experience on this issue yet
  268. # [18:58] <fantasai> hyatt: these types of pseudos have lots of special-cased code to handle these pseudos
  269. # [18:58] <fantasai> hyatt: running a transition on each of these requires extra code
  270. # [18:58] <fantasai> hyatt: how valueable is it to transition these? if nobody really cares, we shouldn't worry about it for a first cut
  271. # [18:58] <fantasai> ?: Would prefer if before/after animate but not the others
  272. # [18:59] <dbaron> s/?:/Brad:/
  273. # [18:59] <fantasai> hyatt: that would work. THey're the most straightforward
  274. # [18:59] <fantasai> dbaron: I don't think it's a question of :before/:after content animate
  275. # [18:59] <fantasai> dbaron: question is can you trigger a transition on the pseudo
  276. # [18:59] <fantasai> I think :before/:after should behave just like normal elements
  277. # [18:59] <fantasai> dean: I don't see why that should not work
  278. # [19:00] * fantasai coudl not hear that
  279. # [19:00] <fantasai> hyatt: I think you can transition on :before/:after and not on others
  280. # [19:00] <fantasai> brad: tree-like pseudo-elements, to capture future elements that work that way/
  281. # [19:01] <fantasai> dbaron: say :before/:after for now but then future pseudos can say which properties apply to them
  282. # [19:01] <fantasai> I think we should just define a term "tree-like pseudo-elements" and use that
  283. # [19:01] <fantasai> then it's easier to plug in new pseudos
  284. # [19:01] <fantasai> Selectors is still Last Call, I can add it in as an editorial change
  285. # [19:02] <fantasai> dbaron: I think coming up with a term is ok
  286. # [19:02] <fantasai> hyatt: what about pseudos for e.g. datagrid? I'm not sure we want to transition those, even though they're probably tree-like
  287. # [19:02] <fantasai> hyatt: I'm not sure tree is the right category
  288. # [19:02] <fantasai> dbaron: There are pseudo-elements that are tree-like and contain elements, tree-like and don't contain elements, and not-tree like
  289. # [19:03] <fantasai> dbaron: we don't have any in the second category, but we discussed some with the Forms wg
  290. # [19:03] <fantasai> hyatt: so let's just say :before/:after explicitly
  291. # [19:03] <fantasai> peter is concerned about conflicts in the specs
  292. # [19:04] <dbaron> s/tree-like and contain elements, tree-like and don't contain elements/tree-like and don't contain elements, tree like and contain elements/
  293. # [19:04] <fantasai> peter: Phrase it carefully
  294. # [19:04] <fantasai> WAIT
  295. # [19:04] <Zakim> -dino
  296. # [19:04] <Zakim> -ChrisL
  297. # [19:04] <Zakim> -[Mozilla]
  298. # [19:04] <Zakim> -Brad_Kemper
  299. # [19:04] <Zakim> -[Microsoft]
  300. # [19:04] <Zakim> -SteveZ
  301. # [19:04] <fantasai> GRRRR
  302. # [19:04] <Zakim> -hyatt
  303. # [19:04] <Zakim> -glazou
  304. # [19:04] <fantasai> we're missing formal resolutions on a couple issues
  305. # [19:04] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
  306. # [19:04] * Parts: dino (dino@17.203.15.167)
  307. # [19:04] <Zakim> -Bert
  308. # [19:05] <Zakim> -cesar_acebal
  309. # [19:05] <fantasai> The color space issue for example
  310. # [19:05] <dbaron> fantasai, I'm not sure that we need formal resolutions on all of these... it's a pretty early draft.
  311. # [19:05] <dbaron> fantasai, the color space one also wasn't on the agenda
  312. # [19:05] * Quits: cesar_acebal (acebal@85.152.176.161) (Quit: cesar_acebal)
  313. # [19:05] <fantasai> we discussed it, if there was agreement it should be noted
  314. # [19:05] <fantasai> esp since I don't think I minuted it correctly
  315. # [19:06] <Zakim> -plinss
  316. # [19:06] <dbaron> fantasai, well, what we agreed on was what the spec already says
  317. # [19:06] <plinss> Are you referring to the discussion of how color values are animated? (in RGB space or HSL space?)
  318. # [19:06] <fantasai> yes
  319. # [19:06] <dbaron> fantasai, and given that no issue was raised about it and the spec is ok, I don't think we need a resolution
  320. # [19:07] <fantasai> RESOLVED: transitions apply to all elements except pseudos other than :before/:after
  321. # [19:07] <dbaron> I'd say "all elements and the :before and :after pseudo-elements"
  322. # [19:07] <fantasai> ok, then can I get a summary? "we agree hsl is better" "we agree rgb is better" "neither one is better" "we dont' care"
  323. # [19:07] <fantasai> etc.
  324. # [19:08] <dbaron> Animations are component-wise in rgb() color space.
  325. # [19:08] <fantasai> ok
  326. # [19:08] <dbaron> Based on what we said about transparent, I think they are component-wise (r, g, b, a) in *premultiplied* rgba() color space, but I'd like to check that with other people
  327. # [19:08] * Quits: alexmog (alexmog@131.107.0.75) (Ping timeout)
  328. # [19:09] <dbaron> I think I raised that as an issue but it wasn't on today's agenda
  329. # [19:09] <fantasai> so did I mistype dean's comments on that issue?
  330. # [19:09] * Joins: alexmog (alexmog@131.107.0.75)
  331. # [19:09] * fantasai thinks she might've swapped rgb and hsl in the minutes
  332. # [19:10] <dbaron> there was one line that I re-minuted right after you minuted it
  333. # [19:10] <fantasai> yeah, got that
  334. # [19:10] <hyatt> dbaron: i believe our implementation just animates each value individually
  335. # [19:10] <hyatt> the r the g the b and the a
  336. # [19:10] <dbaron> "<fantasai> dean: we didn't think it was necessary, hsl just usually gives better results" got it backwards
  337. # [19:11] <fantasai> I'm referring to < fantasai> dean: Someone asked a question about animating colors through different color spaces
  338. # [19:11] <fantasai> 16:40 < fantasai> dean: We did some experiments, and we all thought that it would be better to animate through hsl
  339. # [19:11] <fantasai> 16:40 < fantasai> dean: when you animate through rgb you sometimes wind up with a sort of gray color
  340. # [19:11] <Zakim> disconnecting the lone participant, fantasai, in Style_CSS FP()12:00PM
  341. # [19:11] <Zakim> Style_CSS FP()12:00PM has ended
  342. # [19:11] <Zakim> Attendees were +95089aaaa, +1.858.216.aabb, plinss, +1.281.419.aacc, hyatt, dbaron, +34.60.940.aadd, cesar_acebal, sylvaing, +1.408.588.aaee, Bert, +39.524.9.aaff, fantasai,
  343. # [19:11] <Zakim> ... ChrisL, dino, +1.650.766.aagg, SteveZ, +95089aahh, glazou, arronei, alexmog, Brad_Kemper
  344. # [19:11] <plinss> I would think animating each value independently would give a better result than pre-multiplying...
  345. # [19:11] <hyatt> oh maybe dean changed our impl
  346. # [19:11] <hyatt> i thought we just animated each value individually though
  347. # [19:11] <dbaron> fantasai, and the one line in that that was wrong was the one I just said
  348. # [19:11] <dbaron> hyatt, but then animating from transparent to a color would make it look black-ish at the beginning
  349. # [19:12] <hyatt> sounds like this needs to be an issue?
  350. # [19:12] <dbaron> hyatt, I think I sent a message about it, but it wasn't on today's agenda.
  351. # [19:12] <hyatt> ah ok
  352. # [19:12] <hyatt> maybe we can talk about it next week or something
  353. # [19:12] <dbaron> but yeah, I think it should be an issue
  354. # [19:12] <fantasai> dbaron, so my conclusion is "sometimes hsl is better and sometimes rgb is better but the spec says rgb and we aren't changing it for now"?
  355. # [19:13] <dbaron> fantasai, no
  356. # [19:13] <hyatt> my original (possibly naive) implementation just animated each value
  357. # [19:13] * fantasai has to summarize these things for the record, it's hard to do if one doesn't understand them at all
  358. # [19:13] <dbaron> fantasai, the conclusion was rgb is better
  359. # [19:13] <hyatt> r, g, b, a separately
  360. # [19:13] <dbaron> fantasai, when compared to hsl
  361. # [19:13] <dbaron> fantasai, we're still discussing alpha
  362. # [19:14] <fantasai> so according to my minutes dean originally said hsl was better, and then I missed why it was bad
  363. # [19:14] <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jul/0004.html was where I raised this... but I now think I got it backwards
  364. # [19:14] <dbaron> the alpha issue, that is
  365. # [19:14] <hyatt> yeah we don't pre-multiply
  366. # [19:14] <plinss> no, dean said they tried hsl first, thinking it would be better, but found that it wasn't
  367. # [19:15] <hyatt> we just animate each component
  368. # [19:15] <fantasai> plinss: thank you
  369. # [19:15] <hyatt> each of the 4 components
  370. # [19:15] <dbaron> fantasai, he said he originally thought it would be better, but then did some experiments, which showed that it led to bizarre things
  371. # [19:15] <fantasai> plinss: that's what I needed
  372. # [19:15] * fantasai was sure the minutes didn't make sense as written
  373. # [19:15] <plinss> you get transitions through the hue channel that give weird unrelated colors in the middle...
  374. # [19:15] <dbaron> hyatt, let me write a testcase... I think nonpremultiplied will give bizarre results, though...
  375. # [19:16] <plinss> when moving in saturation or lightness it does work better, but hue gets weird when moving through the 180 degree phase
  376. # [19:17] <plinss> dbaron: I would guess that non-premultiplied would actually give better results, but willing to be proven wrong...
  377. # [19:17] <dbaron> hyatt, though I guess the author can get what they want by specifying different forms of transparent
  378. # [19:18] <fantasai> plinss, e.g. from blue to yellow, you transition through green?
  379. # [19:18] * fantasai studies the diagrams
  380. # [19:19] <fantasai> http://en.wikipedia.org/wiki/HSL_and_HSV
  381. # [19:19] <fantasai> I like HSL diagrams, they're pretty... You've got several options there, could transition aroudn the edges of the circle, or straight through the shortest path
  382. # [19:19] <fantasai> but I'm not sure what calculations it would take
  383. # [19:20] * fantasai doesn't know much about color
  384. # [19:23] <plinss> yeah, you could go through green (which would make sense), or through red depending on which edge you go through (based on subtleties of end points)
  385. # [19:27] * fantasai reads back through the other parts of this meeting to see if they make sense in the minutes
  386. # [19:30] <plinss> Was there anything else you needed?
  387. # [19:30] <fantasai> not immediately, can you check back a bit later maybe?
  388. # [19:30] <fantasai> I'll either post the minutes, or I'll have questions
  389. # [19:31] <plinss> sure
  390. # [19:31] <fantasai> This was the hardest discussion to minute in a very long time I think
  391. # [19:32] <fantasai> RRSAgent: make logs public
  392. # [19:32] <RRSAgent> I have made the request, fantasai
  393. # [19:40] * fantasai thinks sgalineau's comment on IRC about the transitions is very interesting
  394. # [20:10] * Quits: sgalineau (sylvaing@131.107.0.114) (Connection reset by peer)
  395. # [20:17] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  396. # [20:18] * Joins: sgalineau (sylvaing@131.107.0.111)
  397. # [20:29] <sgalineau> fantasai, I think of transitions as really no different from any other property change wrt computed styles; just like start/end are the only DOM events you can handle in the current proposal, start and end values would be the only values you see through the DOM as well as the only values that can inherit. All transitions effectively do at this level is timing the value change. What happens in between is display-only. Conversely, if intermediate prop values d
  398. # [20:32] <fantasai> sgalineau: your comment got cut off after intermediate prop
  399. # [20:32] <sgalineau> Conversely, if intermediate prop values do inherit then I'd expect the DOM to reflect that and I don't know that it's desirable for webdevs or implementors. Caveat: this means nested transitions would always run sequentially.
  400. # [20:33] <fantasai> I'm not sure I understand that last part
  401. # [20:33] <sgalineau> the caveat ?
  402. # [20:33] <fantasai> yeah
  403. # [20:34] <fantasai> I'm not really a transitions expert, though.
  404. # [20:34] * fantasai hasn't been paying too much attention
  405. # [20:34] <sgalineau> if a child doesn't inherit until the parent's transition is complete then it won't start its own transition until then
  406. # [20:34] <hyatt> we do let you get the current animated value in getComputedStyle
  407. # [20:34] <sgalineau> same thing for its child etc
  408. # [20:34] <fantasai> ah, right
  409. # [20:34] <hyatt> so you can see what's going on with the animation in the DOM
  410. # [20:34] <fantasai> I don't think that's wanted
  411. # [20:34] <fantasai> er
  412. # [20:34] <hyatt> i am sure it's wanted
  413. # [20:34] <sgalineau> so it'd all be stepwise
  414. # [20:34] <fantasai> s/I/sgalineau, I/
  415. # [20:34] <hyatt> ah ok :)
  416. # [20:37] <sgalineau> well they can't run all at the same time *and* inherit. that's what you're doing now and it keeps resetting the nested transitions over and over until the parent is done right ? so effectively, you get some weird sequential thing
  417. # [20:38] <sgalineau> so you either 'suspend' inheritance or you hide the intermediate stages imo
  418. # [20:39] <hyatt> you don't suspend inheritance... you just don't start a transition based off an inherited value.
  419. # [20:39] <hyatt> off an inherited animating value
  420. # [20:40] <hyatt> that was the proposed resolution at least
  421. # [20:40] <sgalineau> ok. but once the transition completes, then the end value inherits right ? aren't we getting to the same outcome ?
  422. # [20:40] <hyatt> yeah but that won't start a transition
  423. # [20:41] <hyatt> basically include the start/end values in the special casing
  424. # [20:41] * fantasai adjusts the minutes to reflect that :)
  425. # [20:41] <fantasai> that's much clearer now
  426. # [20:41] <sgalineau> oh, ok. that's the obvious bit i missed. so if the property is changed by inheritance then no transition ?
  427. # [20:42] <sgalineau> or no transition if the inherited value was set by a transition ?
  428. # [20:43] <sgalineau> (this stuff must be fun to code...jealous...)
  429. # [20:44] <fantasai> Minutes sent
  430. # [20:44] <fantasai> hyatt: take a look, and if I've missed anything please send a note in response
  431. # [20:44] * fantasai had a lot of trouble minuting today's discussion
  432. # [20:44] <fantasai> s
  433. # [20:45] <hyatt> ok
  434. # [20:45] <fantasai> thanks :)
  435. # [20:45] <sgalineau> re-reading, it sounds like the latter i.e. if a property is updated by a transition, it will not trigger transitions for the elements that inherit its animated value(s)
  436. # [20:45] <hyatt> sgalineau: yeah that was the suggested resolution
  437. # [20:45] <hyatt> although that is going to be hell to implement
  438. # [20:45] <sgalineau> ok
  439. # [20:45] <hyatt> we really have no way of knowing that in webkit
  440. # [20:46] <sgalineau> well, how about my suggestion ?
  441. # [20:47] <sgalineau> end value may start transition on descendants ?
  442. # [20:47] * Zakim excuses himself; his presence no longer seems to be needed
  443. # [20:47] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  444. # [20:48] <sgalineau> as you hover on something, you may want a short sequence of transitions to happen. nesting them seems natural.
  445. # [20:48] <fantasai> Bert: any progress on publishing flexbox or css3-images?
  446. # [20:49] <fantasai> ChrisL: any ETA on the border-image box-shadow masking text?
  447. # [20:57] * Joins: MoZ (chatzilla@85.189.148.220)
  448. # [20:57] * fantasai guesses http://nicewebtype.com/notes/2009/07/12/rgba-text-shadow-in-safari-firefox/ is because WebKit is using system calls for shadows
  449. # [20:58] * hyatt looks
  450. # [21:00] <hyatt> yeah interesting
  451. # [21:00] <hyatt> that does not seem correct to me
  452. # [21:21] * Quits: MoZ (chatzilla@85.189.148.220) (Ping timeout)
  453. # [21:22] * Joins: MoZ (chatzilla@85.189.148.220)
  454. # [21:25] * Joins: dbaron (dbaron@63.245.220.240)
  455. # [21:30] * Quits: sgalineau (sylvaing@131.107.0.111) (Client exited)
  456. # [21:30] * Joins: sgalineau (sylvaing@131.107.0.112)
  457. # [21:45] <plinss> actually, WebKit's behavior seems more logical to me, how can something that's transparent cast an opaque shadow?
  458. # [21:46] <hyatt> people don't really connect the two
  459. # [21:46] <hyatt> we've already had a bug filed for example about fully transparent text not casting a shadow
  460. # [21:46] <hyatt> that's one trick people want to be able to do that works in firefox
  461. # [21:53] <plinss> I get that there are effects that some people might want that are precluded in WebKit's implementation, it's just one of those things that doesn't work like that in the real world. The shadow is, after all, being cast by the text. Were this an actual shadow, being cast by real light, the opacity of the text would most definitely affect the shadow...
  462. # [21:54] * Quits: sgalineau (sylvaing@131.107.0.112) (Connection reset by peer)
  463. # [21:55] <hyatt> yeah, CSS has kind of consistently come down on the side of these being more like decorative effects though than actual shadows
  464. # [21:55] <hyatt> especially with box-shadow
  465. # [21:55] <plinss> If the designer really wanted the shadow more opaque, they could theoretically specify an opacity for it greater than 1...
  466. # [21:56] <hyatt> opacity is clamped to 0,1
  467. # [21:56] <plinss> I know, that's why I said "theoretically".
  468. # [21:56] <hyatt> also i believe this was resolved already (that fully transparent text still cast a shadow)
  469. # [21:56] <hyatt> seems like this issue has come up already
  470. # [21:56] <hyatt> would have to dig through history to see though
  471. # [21:56] <hyatt> but i seem to recall mozilla bringing this up as an issue
  472. # [21:57] <hyatt> when they found out we didn't cast a shadow for transparent text
  473. # [21:57] <hyatt> and authors keep filing bugs on us about that one
  474. # [21:57] <hyatt> so they expect it to work
  475. # [21:57] <plinss> understood, I'm not proposing changing it, just pointing out that it makes more sense to me the other way, so i presume there are others that will see it that way too...
  476. # [21:57] <hyatt> yeah
  477. # [21:58] <plinss> BTW, I'm glad you made the call today. I hope you can join us on a more regular basis...
  478. # [21:59] <hyatt> yeah was good to hammer out some transitions stuff
  479. # [22:24] * Joins: sgalineau (sylvaing@131.107.0.111)
  480. # [22:38] * fantasai wants to hammer out the border-image box-shadow text so we can publish already
  481. # [22:38] * fantasai suggests adding "poke ChrisL" to next week's agenda
  482. # [22:41] <hyatt> i changed webkit btw to not clip border-image to border-radius
  483. # [22:41] <hyatt> and that shipped in safari 4
  484. # [22:43] <fantasai> nice
  485. # [22:44] <fantasai> did you implement the box-shadow masking thing you and roc were talking about?
  486. # [22:45] <hyatt> nope
  487. # [22:45] <hyatt> would be cool to try that
  488. # [22:45] <hyatt> right now i'm fixing our embarrassing display:run-in bug
  489. # [22:45] <fantasai> heh
  490. # [22:45] <hyatt> that made bz go "you suck"
  491. # [22:46] <fantasai> if you get to working on the masking thing before chrisl writes his spec text let me know, maybe I'll just interrogate you about it instead :)
  492. # [22:46] <fantasai> it's the last thing we need to go to last call
  493. # [22:50] <hyatt> oh really
  494. # [22:50] <hyatt> i can't remember what i suggested
  495. # [22:51] <hyatt> so much work to do to bring webkit up to the latest version of that spec
  496. # [22:56] <fantasai> then maybe we'll hit CR so you won't have to implement -webkit2-border-image :)
  497. # [22:56] * Quits: arronei (arronei@131.107.0.112) (Quit: arronei)
  498. # [22:58] <hyatt> well at LC i think i'm willing to implement non-prefixed
  499. # [22:58] <hyatt> unless you think that's dangerous
  500. # [22:58] <fantasai> I think it really depends on the LC
  501. # [22:59] <fantasai> in this case, the last WD was effectively an LC
  502. # [22:59] <hyatt> it feels very close to "done" to me
  503. # [22:59] <fantasai> yeah
  504. # [23:00] <fantasai> we could have published the last as an LC, but I wanted the formal LC period to be smoother so we published as WD to elicit a round of comments before LC
  505. # [23:02] <hyatt> btw http://www.satine.org/archives/2009/07/11/snow-stack-is-here/ not sure if people had seen that yet
  506. # [23:03] <fantasai> no
  507. # [23:03] <fantasai> although I shouldn't play that on this comp; flash crashes on this system every time :/
  508. # [23:04] <hyatt> http://img269.yfrog.com/img269/3224/benchmark.jpg <-- the best part lol
  509. # [23:06] * Quits: alexmog (alexmog@131.107.0.75) (Ping timeout)
  510. # [23:13] * Joins: alexmog (alexmog@131.107.0.73)
  511. # [23:58] * Quits: MoZ (chatzilla@85.189.148.220) (Ping timeout)
  512. # Session Close: Thu Jul 16 00:00:00 2009

The end :)