/irc-logs / w3c / #css / 2010-03-10 / end

Options:

  1. # Session Start: Wed Mar 10 00:00:00 2010
  2. # Session Ident: #css
  3. # [03:40] * Quits: jdaggett (jdaggett@118.243.226.86) (Quit: jdaggett)
  4. # [03:50] * Joins: TabAtkins (chatzilla@12.229.246.2)
  5. # [04:17] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  6. # [04:18] * Joins: TabAtkins_ (chatzilla@12.229.246.2)
  7. # [04:18] * Quits: TabAtkins (chatzilla@12.229.246.2) (Connection reset by peer)
  8. # [04:19] * TabAtkins_ is now known as TabAtkins
  9. # [05:50] * Quits: Curt` (DorkeyDear@76.243.210.82) (Quit: Leaving)
  10. # [07:37] * Joins: jdaggett (jdaggett@118.243.226.86)
  11. # [08:44] * Quits: TabAtkins (chatzilla@12.229.246.2) (Ping timeout)
  12. # [10:54] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  13. # [10:54] * Joins: jjok (jonathan_j@84.9.187.60)
  14. # [11:14] * Quits: arronei (arronei@131.107.0.105) (Ping timeout)
  15. # [11:16] * Joins: Lachy (Lachlan@213.236.208.22)
  16. # [11:16] * Quits: Lachy (Lachlan@213.236.208.22) (Client exited)
  17. # [11:17] * Joins: Lachy (Lachlan@213.236.208.22)
  18. # [11:19] * Joins: arronei (arronei@131.107.0.75)
  19. # [11:24] * Joins: lstorset (lstorset@213.236.208.22)
  20. # [11:38] * Parts: jjok (jonathan_j@84.9.187.60)
  21. # [12:40] * Quits: lstorset (lstorset@213.236.208.22) (Quit: Leaving.)
  22. # [13:03] * Joins: lstorset (lstorset@213.236.208.22)
  23. # [15:10] * Quits: jdaggett (jdaggett@118.243.226.86) (Quit: jdaggett)
  24. # [16:06] * Joins: TabAtkins (chatzilla@12.229.246.2)
  25. # [16:18] * Quits: TabAtkins (chatzilla@12.229.246.2) (Ping timeout)
  26. # [16:19] * Joins: TabAtkins (chatzilla@12.229.246.2)
  27. # [16:32] * Quits: TabAtkins (chatzilla@12.229.246.2) (Ping timeout)
  28. # [16:48] * Joins: TabAtkins (chatzilla@12.229.246.2)
  29. # [16:52] * Quits: TabAtkins (chatzilla@12.229.246.2) (Ping timeout)
  30. # [17:01] * Joins: oyvind (oyvinds@213.236.208.22)
  31. # [17:02] * Joins: lstorset1 (lstorset@213.236.208.22)
  32. # [17:03] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  33. # [17:03] * Quits: lstorset1 (lstorset@213.236.208.22) (Quit: Leaving.)
  34. # [17:04] * Quits: anne (annevk@83.85.115.123) (Ping timeout)
  35. # [17:07] * Quits: lstorset (lstorset@213.236.208.22) (Quit: Leaving.)
  36. # [17:08] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  37. # [17:08] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  38. # [17:08] <RRSAgent> logging to http://www.w3.org/2010/03/10-CSS-irc
  39. # [17:09] <plinss> rrsagent, make logs public
  40. # [17:09] <RRSAgent> I have made the request, plinss
  41. # [17:09] <plinss> zakim, this will be style
  42. # [17:09] <Zakim> ok, plinss; I see Style_CSS FP()12:00PM scheduled to start in 53 minutes
  43. # [17:14] * Joins: anne (annevk@83.85.115.123)
  44. # [17:19] * Quits: anne (annevk@83.85.115.123) (Ping timeout)
  45. # [17:20] * Joins: Lachy (Lachlan@85.196.122.246)
  46. # [17:25] * Joins: anne (annevk@83.85.115.123)
  47. # [17:26] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  48. # [17:31] * Joins: glazou (glazou@82.247.96.19)
  49. # [17:31] <glazou> Zakim, this will be Style
  50. # [17:31] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 31 minutes
  51. # [17:31] <glazou> RRSAgent, make logs public
  52. # [17:31] <RRSAgent> I have made the request, glazou
  53. # [17:38] * Joins: Lachy (Lachlan@85.196.122.246)
  54. # [17:38] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  55. # [17:39] * Joins: sylvaing (sylvaing@76.104.131.10)
  56. # [17:47] * Joins: Lachy (Lachlan@85.196.122.246)
  57. # [17:48] * sylvaing test123
  58. # [17:58] * Joins: bradk (bradk@67.188.133.45)
  59. # [18:00] <Zakim> Style_CSS FP()12:00PM has now started
  60. # [18:00] <Zakim> +plinss
  61. # [18:00] <glazou> plinss: arrrgl
  62. # [18:00] <glazou> my phne does not work !!!!
  63. # [18:00] <plinss> nice
  64. # [18:01] * Joins: TabAtkins (chatzilla@64.168.229.50)
  65. # [18:01] <plinss> device problem or line problem?
  66. # [18:01] * Joins: smfr (smfr@68.183.233.11)
  67. # [18:01] <glazou> don't know yet
  68. # [18:01] * Joins: ChrisL (ChrisL@128.30.52.169)
  69. # [18:01] <glazou> give me a few seconds
  70. # [18:01] <sylvaing> hadopi strikes again
  71. # [18:01] <plinss> sure
  72. # [18:02] <Zakim> +sylvaing
  73. # [18:02] <glazou> aaaah better
  74. # [18:02] <Zakim> +bradk
  75. # [18:02] <Zakim> +glazou
  76. # [18:03] <Zakim> +Bert
  77. # [18:03] <Zakim> +smfr
  78. # [18:04] <Zakim> +[Microsoft]
  79. # [18:04] <arronei> zakim, microsoft is me
  80. # [18:04] <Zakim> +arronei; got it
  81. # [18:05] * Joins: lstorset (lastorset@84.215.115.49)
  82. # [18:05] * TabAtkins is here in chat, will be gone in 20 minutes or so when loading onto the plane.
  83. # [18:05] <glazou> ok TabAtkins
  84. # [18:05] <glazou> no worries
  85. # [18:05] <smfr> i might get called away too (construction people at the house)
  86. # [18:06] <Zakim> + +39.524.9.aaaa
  87. # [18:06] <glazou> ahlala :)
  88. # [18:06] <lstorset> same here
  89. # [18:06] <ChrisL> zakim, aa is me
  90. # [18:06] <Zakim> sorry, ChrisL, I do not recognize a party named 'aa'
  91. # [18:06] <ChrisL> zakim, +aa is me
  92. # [18:06] <Zakim> sorry, ChrisL, I do not recognize a party named '+aa'
  93. # [18:06] <TabAtkins> zakim, aaaa is ChrisL
  94. # [18:06] <Zakim> +ChrisL; got it
  95. # [18:06] <Zakim> +SteveZ
  96. # [18:06] <ChrisL> zakim, +39 s me
  97. # [18:06] <Zakim> I don't understand '+39 s me', ChrisL
  98. # [18:06] <glazou> Zakim, aaaa is ChrisL
  99. # [18:06] <Zakim> sorry, glazou, I do not recognize a party named 'aaaa'
  100. # [18:07] * TabAtkins I already got him
  101. # [18:07] <Zakim> +[Mozilla]
  102. # [18:07] <ChrisL> zakim, +39 is me
  103. # [18:07] <Zakim> sorry, ChrisL, I do not recognize a party named '+39'
  104. # [18:07] <Zakim> +??P22
  105. # [18:07] <ChrisL> zakim, ++39 is me
  106. # [18:07] <Zakim> sorry, ChrisL, I do not recognize a party named '++39'
  107. # [18:07] * TabAtkins Chris, I got you already.
  108. # [18:07] <plinss> zakim, ??P22 is lstorset
  109. # [18:07] <Zakim> +lstorset; got it
  110. # [18:07] * Joins: dbaron (dbaron@63.245.220.240)
  111. # [18:08] * TabAtkins You just have to use the full four letters in your mask.
  112. # [18:08] * dbaron Zakim, who is on the phone?
  113. # [18:08] * Zakim sees on the phone: plinss, sylvaing, bradk, glazou, Bert, smfr, arronei, ChrisL, SteveZ, [Mozilla], lstorset
  114. # [18:08] <Zakim> +??P26
  115. # [18:08] * dbaron Zakim, [Mozilla] is dbaron
  116. # [18:08] * Zakim +dbaron; got it
  117. # [18:08] * dbaron Zakim, ??P26 is fantasai
  118. # [18:08] * Zakim +fantasai; got it
  119. # [18:08] <fantasai> ScribeNick: fantasai
  120. # [18:09] <fantasai> Daniel: Extra agenda items?
  121. # [18:09] <fantasai> Peter: If you're planning to come to F2F, please remember to fill out questionnaire so dsinger has an accurate count
  122. # [18:09] <plinss> http://www.w3.org/2002/09/wbs/32061/css-wg-cupertino-2010/
  123. # [18:09] * Bert thinks the International Women's Day must be over... :-)
  124. # [18:10] <fantasai> Daniel: jdaggett was unable to make call, and so we will defer fonts discussion to next week
  125. # [18:10] <glazou> http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html
  126. # [18:10] <fantasai> Topic: Media Queries feature for widgets
  127. # [18:11] <fantasai> Daniel: Used to detect view mode of widget: minimized, maximized, fullscreen, etc.
  128. # [18:11] <fantasai> Chris: This should not be restricted to widgets, there are plenty of other cases you'd want this info
  129. # [18:11] <fantasai> Daniel: That is my comment also. I think all these mode could apply generally
  130. # [18:11] <fantasai> Daniel: Should live outside of widgets
  131. # [18:12] <fantasai> dbaron: The all value doesn't seem especially useful, since it's always true
  132. # [18:12] <fantasai> ?: Like @media all
  133. # [18:12] <fantasai> dbaron: Might as well not query on feature
  134. # [18:12] <ChrisL> maybe all means "I don't know"
  135. # [18:12] <fantasai> dbaron: Some of these have intersections
  136. # [18:12] <fantasai> dbaron: e.g. I can see both fullscreen and application being true
  137. # [18:13] <fantasai> dbaron: and fullscreen and not-application being true
  138. # [18:13] <fantasai> dbaron: So it seems like there are two different axes here
  139. # [18:13] <ChrisL> application+maximized, application+mini are sensible combinations
  140. # [18:13] <fantasai> Daniel: yeah, application doesn't seem to be a view mode
  141. # [18:13] <fantasai> discussion of various combinations
  142. # [18:14] <fantasai> Chris: There's no value for a normal window, that's not fullscreen
  143. # [18:14] <fantasai> Bert: I thought that was what 'application' meant
  144. # [18:14] <fantasai> dbaron: Seems some of these definitions could be a little clearer
  145. # [18:14] <fantasai> Brad: If they changed application to windowed, it would make more sense to me
  146. # [18:14] <fantasai> Chris: They might be saying something about the presence of chrome
  147. # [18:15] <fantasai> Bert: Not sure you can always tell the difference between application and floating
  148. # [18:15] <fantasai> Bert: Application may have chrome added itself, or chrome added by WM
  149. # [18:16] <fantasai> smfr: Another difference is that for floating, the viewport background is transparent
  150. # [18:16] <fantasai> Brad: Are Opera's widgets floating, then?
  151. # [18:16] <fantasai> smfr: Haven't seen those, but dashboard on Mac is like that
  152. # [18:16] <fantasai> ?: THey're not transparent, but other criteria seem to fit
  153. # [18:16] * dbaron Zakim, who is noisy?
  154. # [18:16] * Zakim dbaron, listening for 10 seconds I heard sound from the following: lstorset (51%)
  155. # [18:16] <lstorset> ? is lstorset
  156. # [18:17] <ChrisL> floating seems to apply to things like the classic round clock widget
  157. # [18:17] <sylvaing> how much chrome is chrome ?
  158. # [18:17] <smfr> someone is on speakerphone
  159. # [18:17] * dbaron thinks lstorset is causing echo
  160. # [18:17] <lstorset> sorry that was me
  161. # [18:17] <fantasai> Daniel: Ok, that's all about comments on values?
  162. # [18:17] <fantasai> Steve: Looking at this thing, it seems to be a weird combination of CSS features
  163. # [18:17] <fantasai> Steve: Background seems it ought to come from content -- it's transparent or it isn't
  164. # [18:17] <oyvind> opera widgets do have transparent backgrounds I think
  165. # [18:17] <fantasai> Steve: in a CSS window it's normally transparent
  166. # [18:18] <fantasai> Steve: I find it hard to figure out besides maximize and mini what the other things are trying to say
  167. # [18:18] <ChrisL> from their definitions, "The chrome comprises the visible parts of the user agent that do not depend on the content (e.g. tool bars, title bars, menus). " which seems to disallw pseudo-chrome drawn by the content itself (its own menus etc)
  168. # [18:18] <fantasai> Steve: And wondering why these aren't CSS properties
  169. # [18:18] <fantasai> Steve: This discussion seems very similar to the one we were having on fit
  170. # [18:18] <fantasai> smfr: These are media /queries/. You're not describing what the content looks like
  171. # [18:18] <fantasai> smfr: you're querying the environment
  172. # [18:19] <fantasai> Sylvain: You can write media queries based on viewport space you have, but this is a little highger level
  173. # [18:19] <fantasai> Daniel: You can write media queries to check size of viewport, but not that the size of viewport matches size of screen
  174. # [18:20] <fantasai> howcome?: Do people want to query whether the window is visible?
  175. # [18:20] <fantasai> Sylvain: You get into is my window visible, do I have focus, etc.
  176. # [18:20] <fantasai> Sylvain: I kinda like it, but it's not exactly querying the media
  177. # [18:20] <fantasai> Daniel: We already discussed adding values that are more system-based to Media queries
  178. # [18:21] <fantasai> Sylvain: I can see the value, but is it something solely through CSS?
  179. # [18:21] <fantasai> Sylvain: I can see you wnting to access this event-based
  180. # [18:21] <fantasai> fantasai points out that Media Queries isn't a *CSS* spec per se, and it's used in HTMl5 and DOM apis etc too
  181. # [18:22] <fantasai> Steve: The other thing I was hearing was the possible lack of orthogonality
  182. # [18:22] <fantasai> Steve: Of the distinctions between minimized and fullscreen vs. whether chrome is present or not
  183. # [18:22] <fantasai> smfr: Another question -- are these orthogonal to the media type?
  184. # [18:23] <fantasai> smfr: E.g. if I'm in projection mode, do I assume i'm fullscreen?
  185. # [18:23] <fantasai> smfr: Is it possible to be floating but also have a media type of projection?
  186. # [18:23] <fantasai> smfr: I think the spec needs to say something about how those two interact
  187. # [18:23] <fantasai> Daniel: I think projection could imply fullscreen, based on the definitions in CSS
  188. # [18:24] <fantasai> Sylvain: Opera uses projection mode when fullscreened
  189. # [18:24] <fantasai> Daniel: maximize also make sense, mini makes sense...
  190. # [18:24] <fantasai> Daniel: The only one that doesn't make much sense in a browser woudl be floating
  191. # [18:24] <fantasai> Chris: Unless you're a widget in Opera
  192. # [18:24] <fantasai> Daniel: but then your'e a widget
  193. # [18:25] <fantasai> Chris: THe browser is running, but instead of producing a normal window it's showing a widget
  194. # [18:25] <fantasai> Bert: Web pages on the desktop don't have a background either
  195. # [18:25] <fantasai> ?: would be fullscreen
  196. # [18:25] <fantasai> Bert: Not necessarily
  197. # [18:25] <fantasai> Steve: Might make sense for someone from the widgets group to join our call
  198. # [18:26] <fantasai> Chris: We're painting ourselves in a corner here, we're saying they're general and should be applied everywher,e then saying they're not quite general...
  199. # [18:26] <fantasai> Steve: maybe the answer is to work with them to come upw ith values that are general enough to use in the general case but still answer their needs
  200. # [18:26] <fantasai> Daniel: I will make a response to WepApps group summarizing what we just said.
  201. # [18:26] <fantasai> Daniel: Any other comments?
  202. # [18:27] <fantasai> ACTION: Daniel Respond to WAF
  203. # [18:27] * trackbot noticed an ACTION. Trying to create it.
  204. # [18:27] * RRSAgent records action 1
  205. # [18:27] <trackbot> Created ACTION-207 - Respond to WAF [on Daniel Glazman - due 2010-03-17].
  206. # [18:27] <fantasai> Steve: one other comment -- there's a possible feedback group
  207. # [18:27] <fantasai> Steve: To the extent CSS can control what the OS thinks it's doing.. could get a feedback loop
  208. # [18:28] <fantasai> Chris: The value is not maintained live
  209. # [18:28] <fantasai> dbaron: It is maintained live
  210. # [18:28] <fantasai> Daniel: If you query the background, and set it in CSS
  211. # [18:29] <fantasai> fantasai: I think if you are querying the background, you would be checking the background of the canvas itself, not the background assigned to be painted (or not painted) on the canvas
  212. # [18:29] <oyvind> "To avoid circular dependencies, it is never necessary to apply the style sheet in order to evaluate expressions" --MQ
  213. # [18:29] <fantasai> Steve: Need to define interaction of CSS settings and the queries
  214. # [18:30] <fantasai> Daniel: Next item
  215. # [18:30] <fantasai> Topic: vendor prefixes
  216. # [18:30] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0235.html
  217. # [18:31] <fantasai> Daniel: I did not follow the whole thread on that
  218. # [18:31] <fantasai> Daniel: I think the way we handle vendor prefixes in CSS is too monolithic
  219. # [18:31] <fantasai> Daniel: We only remove them when one complete spec moves to CR
  220. # [18:31] <ChrisL> rounded corners!!
  221. # [18:31] <fantasai> Daniel: While some properties could remove prefix long before that
  222. # [18:31] <fantasai> Daniel: I think it should be decision of the group
  223. # [18:32] <fantasai> Bert: I don't think we should not create an extra process in addition to what's provided by W3C
  224. # [18:32] * Quits: TabAtkins (chatzilla@64.168.229.50) (Ping timeout)
  225. # [18:32] <fantasai> Daniel: We have many examples of live properties shipped in browsers that web authors must manipulate in four or five flavors
  226. # [18:33] <fantasai> Daniel: What we did with border-radius, border-radius was at least partially interoperable in most browsers but people had to use five variants
  227. # [18:33] <ChrisL> we have combinations of ultra-stable and rapidly changing properties in the same spec. We don't want to split into smaller and smaller specs all the time
  228. # [18:34] <fantasai> Daniel: When the group decides that a property is stable and interoperable enough, then the prefix can be removed
  229. # [18:34] <fantasai> Bert: Then you need another WD
  230. # [18:34] <fantasai> smfr: That would be an annotation in the draft
  231. # [18:34] <fantasai> s/draft/existing/
  232. # [18:34] <fantasai> er
  233. # [18:34] <fantasai> s/existing/existing draft/
  234. # [18:34] <fantasai> Daniel: Or have a prefix for the WG, but something for all browsers
  235. # [18:35] <fantasai> Chris: That would allow you to change the name
  236. # [18:35] <ChrisL> stability annotations in the draft. like ednotes point out areas of instability; mark certain properties as very stable and unlikely to be changed
  237. # [18:35] <fantasai> Smfr: Could allow changes in syntax then
  238. # [18:35] <fantasai> Steve: Would make one comment -- point of CR is that a) you've had significant public review, not just wg review, and b) you're ready for implementation
  239. # [18:36] <fantasai> Daniel: But in some cases implementations precede CR by years
  240. # [18:36] <fantasai> ...
  241. # [18:37] <fantasai> Steve: If you change the syntax, you'll need to change the prefix
  242. # [18:37] <fantasai> Sylvain: My concern is that you're trying to eliminate the prefixes, but might wind up increasing prefixes.
  243. # [18:38] <fantasai> Sylvain: If implementations start under their own prefixes for very experimental things, you'll wind up with a prefix on top of all the others.
  244. # [18:38] <fantasai> Smfr: I don't think the browser ship cycle is fast enough to make this useful. We don't drop prefixes as soon as we got to CR
  245. # [18:38] <fantasai> Sylvain: border-radius is a good example ...
  246. # [18:39] * fantasai sylvaing I missed your comment
  247. # [18:39] <fantasai> Daniel: Users tend to use the most recent browser versions
  248. # [18:39] <fantasai> Daniel: border-radius is not the only example
  249. # [18:39] <fantasai> Daniel: 2D Transformations is only 2 years old, but has a lot of implementations
  250. # [18:40] <fantasai> Sylvain: The author has to remember which browsers are -vendor-, -w3c-, or no prefix
  251. # [18:40] <fantasai> Sylvain: They have to track versioning to get the right result
  252. # [18:40] <dbaron> Yeah, it's not clear to me that this proposal will make things less complicated for authors rather than more.
  253. # [18:40] <fantasai> Sylvain: We're just adding this uber prefix to the mix, but it's not going to remove other ones at least not soon
  254. # [18:40] <fantasai> Brad: Yeah, I'll wind up with -moz, -ms, and -w3c
  255. # [18:41] <Zakim> +SteveZ.a
  256. # [18:41] <Zakim> -SteveZ
  257. # [18:41] <fantasai> Sylvain: What I'm trying to point out that the goal is to replace what is out there today.
  258. # [18:41] <fantasai> Sylvain: And if that's the goal, then we have to also remove vendor-specific properties
  259. # [18:41] <fantasai> Daniel: If i listent to Brad, he has to support vendor prefixes no matter what we do
  260. # [18:42] * dbaron Zakim, who is noisy?
  261. # [18:42] * Zakim dbaron, listening for 10 seconds I heard sound from the following: bradk (14%), glazou (27%)
  262. # [18:42] <fantasai> Daniel: I think that's all we have to say for now on this topic.
  263. # [18:42] <fantasai> Daniel: Is it something we want to discuss again at the F2F?
  264. # [18:42] <fantasai> Daniel: Ok, no consensus. Let's move on
  265. # [18:43] <fantasai> Topic: Namespace rule in object model
  266. # [18:43] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Mar/0006.html
  267. # [18:43] <fantasai> Daniel: I think Anne answered my points
  268. # [18:44] <fantasai> Peter: The way we do numbering scheme in rule types in the object model is very fragile
  269. # [18:44] * ChrisL slips out for a moment
  270. # [18:44] <ChrisL> zakim, mute me
  271. # [18:44] <Zakim> ChrisL should now be muted
  272. # [18:44] <fantasai> Peter: Having sequential integer values... looking at WebKit's implementation, they add values for their experimental stuff
  273. # [18:44] <anne> I guess in theory we could do away with .type altogether
  274. # [18:44] <fantasai> Peter: Paged Media adds many new at-rules
  275. # [18:44] <fantasai> Peter: We need some way of compartmentalizing modules
  276. # [18:44] <anne> You could just do typeof...
  277. # [18:45] * bradk wasn't the one with the background voices
  278. # [18:45] <fantasai> Daniel: Does it require dicussion at Hypertext coordination group?
  279. # [18:45] <fantasai> Topic: Animations fill modes follow-up
  280. # [18:45] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Mar/0010.html
  281. # [18:45] <fantasai> Smfr: I sent out a revised proposal
  282. # [18:45] <fantasai> Smfr: Little bit of feedback, but people seem happy with it generally
  283. # [18:46] <anne> glazou, I don't think so; since the CSS WG mints new at-rules we can also hand out numbers for them
  284. # [18:46] <fantasai> Smfr: Anybody have comments on that?
  285. # [18:46] <anne> glazou, implementors should just use values >1000 or some such
  286. # [18:46] <glazou> anne: still, coordination is needed to avoid collisions
  287. # [18:46] <fantasai> Bert: I haven't understood it well, but it seems to me that before and after the animation there are other properties that say what style it has
  288. # [18:46] <fantasai> Smfr: So what happens here is that during the animation, the animation rules override
  289. # [18:47] <fantasai> Smfr: The animation is active when the animation name property is in scope
  290. # [18:47] <fantasai> Smfr: The animation is active for the duration ....
  291. # [18:47] <fantasai> Smfr: The effect of the animation goes away when the animation ends
  292. # [18:47] <fantasai> Smfr: With fill-mode, you are extending the effect of the animation into the future until you remove the animation name property
  293. # [18:47] <fantasai> Smfr: Does that make sense?
  294. # [18:48] <fantasai> Bert: I don't know if it's really necessary. It sounds like there's now two ways to specify the style of something, that's one way too many
  295. # [18:48] <fantasai> Smfr: Authors often use JS to add and remove animations, and without this it's hard for them to know that they've avoided visual glitches
  296. # [18:48] <dbaron> I think this sounds fine, modulo the revisions we discussed to fix it so that it defines the correct keyframe to be extended in the presence of some of the other properties
  297. # [18:48] <fantasai> Daniel: I had this problem when I wrote an animation
  298. # [18:49] * ChrisL is back
  299. # [18:49] <fantasai> Smfr: Would like to say one othe rthing about htis. If you're using a fill-mode to extend the animation, and your'e using computedStyle, you'll get the style from those key frames
  300. # [18:49] <ChrisL> zakim, unmute me
  301. # [18:49] <Zakim> ChrisL should no longer be muted
  302. # [18:49] <fantasai> Smfr: It ... an API that let's you know where the style is coming from
  303. # [18:49] <fantasai> Smfr: It's not really obvious where those styles are coming from
  304. # [18:49] <fantasai> Smfr: So an API like currentStyle might have problems with this
  305. # [18:50] <fantasai> dbaron: There's also API requests to say which rules match
  306. # [18:50] <fantasai> Chris: How do you identify the rules?
  307. # [18:50] <fantasai> dbaron: by object: there are rule objects in the OM
  308. # [18:51] <fantasai> Daniel: Ok, what's the next step?
  309. # [18:51] <fantasai> Smfr: Add animation-fill-mode to the animations draft.
  310. # [18:51] <fantasai> Smfr: Then at some point look at that draft and decide if we want to move forward on that
  311. # [18:52] <fantasai> Steve: If I understand the meaning, it is extending the animation. Why is it called fill-mode and not something related to duration?
  312. # [18:52] <fantasai> Smfr: You might have an animation that repeats 3 times of 1 second each.
  313. # [18:52] <fantasai> Smfr: Fill-mode doesn't say what the duration is, it says how you finish (?)
  314. # [18:52] <fantasai> Steve: I'm just concerned about fill having a completely different meaning in the rest of CSS and SVG
  315. # [18:52] <fantasai> Smfr: That's a fair comment, we cna try to think of alternate names
  316. # [18:53] <fantasai> dbaron: I think I had a similar confusion when I first read the spec.
  317. # [18:53] <fantasai> dbaron: I thought it had something to do with repetition
  318. # [18:53] <ChrisL> yes, SVG has to distinguish 2 attrs (on different elements) both called fill. fill is an awful name for the extended duration.
  319. # [18:53] <fantasai> dbaron: Maybe the spec text could explain it better?
  320. # [18:53] <fantasai> Sylvain: Basically it persiststs the DOM in the state of its last keyframe, right?
  321. # [18:53] <fantasai> Smfr: Yes
  322. # [18:53] <fantasai> Sylvain: Yeah, the naming threw me off too
  323. # [18:54] <fantasai> Chris: SVG would love a better name
  324. # [18:54] <fantasai> Smfr: suggestions?
  325. # [18:54] <fantasai> animation-finish-mode?
  326. # [18:55] <fantasai> animation-persist
  327. # [18:55] <ChrisL> endmode
  328. # [18:55] <ChrisL> persistence
  329. # [18:55] <fantasai> Smfr: It also has a backwards-extend ability
  330. # [18:56] <fantasai> .. missed explanation
  331. # [18:56] <smfr> fill-mode: backwards will cause the first keyframe to be applied when animation-delay is non-zero
  332. # [18:56] <fantasai> Daniel: We seem to agree on the revised proposal, so let's add that to the spec and leave the research for a better name in the background
  333. # [18:56] <fantasai> fantasai: could add an issue not to the spec
  334. # [18:57] <fantasai> Steve: I think if you follow dbaron's suggestion to improve the text, you might find the name falls out of that process
  335. # [18:57] <fantasai> Steve: It does sound like a duration envelope
  336. # [18:57] <ChrisL> http://www.w3.org/TR/SMIL/smil-timing.html#adef-fill
  337. # [18:57] <fantasai> Steve: Some examples with the delays, etc. would help
  338. # [18:57] <fantasai> Daniel: Anything else on this topic?
  339. # [18:57] <fantasai> Daniel: We have only five remaining minutes
  340. # [18:58] <fantasai> Daniel: Not enough time for other agenda items. Other suggestions?
  341. # [18:58] <fantasai> dbaron: Reminder about time change next week? :)
  342. # [18:58] <fantasai> Daniel: People based in Europe will have to call one hour early
  343. # [18:58] <fantasai> dbaron: The other thing is the travel time change might be one hour smaller as well
  344. # [18:59] <fantasai> dbaron: depends whether you travel Saturday or Sunday
  345. # [18:59] <fantasai> Steve: you should warn jdaggett
  346. # [18:59] <fantasai> Daniel: F2F is approaching, still gathering agenda items
  347. # [19:00] <fantasai> Daniel: Please send proposals and ifll in the wiki page
  348. # [19:00] <smfr> paste link to wiki page?
  349. # [19:00] <fantasai> http://wiki.csswg.org/planning/cupertino-2010
  350. # [19:00] <smfr> thanks fantasai
  351. # [19:00] <fantasai> Chris: Wrt SVG joint meeting -- there was a DOM event that some people were planning to come out for
  352. # [19:01] <fantasai> Chris: but it has been cancelled, so we will not be able to do a joint SVG meeting
  353. # [19:01] <fantasai> Chris: We should look to TPAC for joint discussions
  354. # [19:01] <fantasai> Meeting closed.
  355. # [19:01] <Zakim> -SteveZ.a
  356. # [19:01] <Zakim> -smfr
  357. # [19:01] <Zakim> -sylvaing
  358. # [19:01] <Zakim> -plinss
  359. # [19:01] <Zakim> -ChrisL
  360. # [19:01] <Zakim> -arronei
  361. # [19:01] <Zakim> -dbaron
  362. # [19:01] <Zakim> -fantasai
  363. # [19:01] <Zakim> -glazou
  364. # [19:01] <Zakim> -Bert
  365. # [19:01] <fantasai> RRSAgent: make logs public
  366. # [19:01] <RRSAgent> I have made the request, fantasai
  367. # [19:01] <Zakim> -lstorset
  368. # [19:01] <Zakim> -bradk
  369. # [19:01] <fantasai> RRSAgent: make minutes
  370. # [19:01] <RRSAgent> I have made the request to generate http://www.w3.org/2010/03/10-CSS-minutes.html fantasai
  371. # [19:01] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
  372. # [19:01] <Zakim> Style_CSS FP()12:00PM has ended
  373. # [19:01] <Zakim> Attendees were plinss, sylvaing, bradk, glazou, Bert, smfr, arronei, +39.524.9.aaaa, ChrisL, SteveZ, lstorset, dbaron, fantasai
  374. # [19:02] * Parts: glazou (glazou@82.247.96.19)
  375. # [19:02] * Quits: sylvaing (sylvaing@76.104.131.10) (Quit: sylvaing)
  376. # [19:04] * Quits: lstorset (lastorset@84.215.115.49) (Quit: Leaving.)
  377. # [19:07] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
  378. # [19:22] * Parts: smfr (smfr@68.183.233.11)
  379. # [19:41] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
  380. # [20:59] * Zakim excuses himself; his presence no longer seems to be needed
  381. # [20:59] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  382. # [21:28] * Joins: jdaggett (jdaggett@118.243.226.86)
  383. # [23:37] * RRSAgent excuses himself; his presence no longer seems to be needed
  384. # [23:37] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
  385. # [23:40] * Quits: anne (annevk@83.85.115.123) (Client exited)
  386. # [23:40] * Joins: anne (annevk@83.85.115.123)
  387. # [23:47] * Quits: jdaggett (jdaggett@118.243.226.86) (Quit: jdaggett)
  388. # Session Close: Thu Mar 11 00:00:00 2010

The end :)