/irc-logs / w3c / #css / 2014-07-30 / end

Options:

  1. # Session Start: Wed Jul 30 00:00:00 2014
  2. # Session Ident: #css
  3. # [00:02] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  4. # [00:02] * Joins: glenn_ (~gadams@public.cloak)
  5. # [00:07] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  6. # [00:20] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  7. # [00:20] * Joins: antonp (~Thunderbird@public.cloak)
  8. # [00:26] * Joins: lmcliste_ (~lmclister@public.cloak)
  9. # [00:26] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  10. # [00:27] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
  11. # [00:27] * Joins: lmclister (~lmclister@public.cloak)
  12. # [00:31] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
  13. # [00:58] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  14. # [00:59] * Joins: glenn (~gadams@public.cloak)
  15. # [01:01] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  16. # [01:05] * Joins: glenn_ (~gadams@public.cloak)
  17. # [01:07] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  18. # [01:11] * Joins: rhauck (~rhauck@public.cloak)
  19. # [01:13] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  20. # [01:14] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
  21. # [01:18] * Joins: glenn (~gadams@public.cloak)
  22. # [01:28] * Joins: glenn_ (~gadams@public.cloak)
  23. # [01:33] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  24. # [01:35] * Joins: glenn (~gadams@public.cloak)
  25. # [01:40] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  26. # [01:54] * Joins: tantek (~tantek@public.cloak)
  27. # [02:02] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
  28. # [02:06] * Joins: tantek (~tantek@public.cloak)
  29. # [02:10] * Joins: tommyjtl (~tommyjtl@public.cloak)
  30. # [02:15] * Quits: lmclister (~lmclister@public.cloak) ("")
  31. # [02:31] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
  32. # [02:40] * Joins: glenn_ (~gadams@public.cloak)
  33. # [02:43] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  34. # [02:49] * Quits: rhauck (~rhauck@public.cloak) ("Leaving.")
  35. # [02:59] * Joins: tommyjtl (~tommyjtl@public.cloak)
  36. # [03:19] * Joins: glenn (~gadams@public.cloak)
  37. # [03:21] * Joins: glenn__ (~gadams@public.cloak)
  38. # [03:23] * leaverou is now known as leaverou_away
  39. # [03:23] * Joins: glenn___ (~gadams@public.cloak)
  40. # [03:24] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  41. # [03:26] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  42. # [03:29] * Quits: glenn__ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  43. # [04:00] * Joins: glenn (~gadams@public.cloak)
  44. # [04:04] * Quits: tantek (~tantek@public.cloak) (tantek)
  45. # [04:06] * Quits: glenn___ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  46. # [04:36] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
  47. # [04:56] * Joins: tommyjtl (~tommyjtl@public.cloak)
  48. # [05:02] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
  49. # [05:02] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
  50. # [05:09] * leaverou_away is now known as leaverou
  51. # [05:26] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
  52. # [05:26] * Joins: tommyjtl (~tommyjtl@public.cloak)
  53. # [05:28] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
  54. # [05:33] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
  55. # [05:52] * Joins: glenn_ (~gadams@public.cloak)
  56. # [05:57] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  57. # [06:02] * Joins: glenn (~gadams@public.cloak)
  58. # [06:07] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  59. # [06:41] * leaverou is now known as leaverou_away
  60. # [06:50] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
  61. # [06:51] * Joins: tommyjtl (~tommyjtl@public.cloak)
  62. # [06:58] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
  63. # [07:04] * Joins: tommyjtl (~tommyjtl@public.cloak)
  64. # [07:14] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
  65. # [07:59] * Joins: glenn_ (~gadams@public.cloak)
  66. # [08:03] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  67. # [08:11] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  68. # [08:11] * Joins: tantek (~tantek@public.cloak)
  69. # [08:36] * leaverou_away is now known as leaverou
  70. # [08:37] * Joins: dbaron (~dbaron@public.cloak)
  71. # [08:42] * Joins: glenn (~gadams@public.cloak)
  72. # [08:47] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  73. # [08:48] * leaverou is now known as leaverou_away
  74. # [08:58] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
  75. # [08:58] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
  76. # [09:03] * Joins: tommyjtl (~tommyjtl@public.cloak)
  77. # [09:03] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
  78. # [09:21] * Joins: Ms2ger (~Ms2ger@public.cloak)
  79. # [09:33] * Joins: glenn_ (~gadams@public.cloak)
  80. # [09:38] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  81. # [09:40] * Joins: glenn (~gadams@public.cloak)
  82. # [09:44] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  83. # [09:54] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
  84. # [10:02] * Joins: tommyjtl (~tommyjtl@public.cloak)
  85. # [10:11] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  86. # [10:12] * Joins: glenn_ (~gadams@public.cloak)
  87. # [10:14] * Joins: glenn__ (~gadams@public.cloak)
  88. # [10:17] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  89. # [10:20] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  90. # [10:41] * leaverou_away is now known as leaverou
  91. # [10:52] * leaverou is now known as leaverou_away
  92. # [11:06] * Joins: liam (liam@public.cloak)
  93. # [11:07] * Quits: tantek (~tantek@public.cloak) (tantek)
  94. # [11:22] * Joins: glenn (~gadams@public.cloak)
  95. # [11:26] * Quits: glenn__ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  96. # [11:30] * Joins: glenn_ (~gadams@public.cloak)
  97. # [11:34] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  98. # [11:56] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
  99. # [11:56] * Joins: tommyjtl (~tommyjtl@public.cloak)
  100. # [12:03] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
  101. # [12:05] * leaverou_away is now known as leaverou
  102. # [12:16] * leaverou is now known as leaverou_away
  103. # [12:45] * leaverou_away is now known as leaverou
  104. # [13:05] * Joins: plh (plehegar@public.cloak)
  105. # [13:10] * Quits: plh (plehegar@public.cloak) ("Leaving")
  106. # [13:34] * leaverou is now known as leaverou_away
  107. # [13:35] * leaverou_away is now known as leaverou
  108. # [13:49] * Quits: Bert (bbos@public.cloak) (Client closed connection)
  109. # [13:54] * Joins: Bert (bbos@public.cloak)
  110. # [13:57] * Joins: tommyjtl (~tommyjtl@public.cloak)
  111. # [14:41] * Joins: glenn (~gadams@public.cloak)
  112. # [14:46] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  113. # [15:47] * leaverou is now known as leaverou_away
  114. # [15:57] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
  115. # [16:01] * Joins: tommyjtl (~tommyjtl@public.cloak)
  116. # [16:24] * leaverou_away is now known as leaverou
  117. # [16:33] * Joins: dwim_home (~Dongwoo@public.cloak)
  118. # [16:33] * Quits: dwim_home (~Dongwoo@public.cloak) ("Leaving")
  119. # [16:36] * leaverou is now known as leaverou_away
  120. # [16:48] * Quits: tommyjtl (~tommyjtl@public.cloak) ("brb")
  121. # [17:06] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
  122. # [17:12] * Joins: dbaron (~dbaron@public.cloak)
  123. # [17:16] * Joins: adenilson (~anonymous@public.cloak)
  124. # [17:18] * Joins: Ms2ger (~Ms2ger@public.cloak)
  125. # [17:32] * Joins: lmclister (~lmclister@public.cloak)
  126. # [17:38] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
  127. # [17:40] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
  128. # [17:51] * Joins: antonp (~Thunderbird@public.cloak)
  129. # [17:52] * Joins: dael (~dael@public.cloak)
  130. # [17:57] * leaverou_away is now known as leaverou
  131. # [17:58] * Joins: alex_antennahouse (~458c94ae@public.cloak)
  132. # [18:00] * Joins: AH_Miller (~mike@public.cloak)
  133. # [18:00] <gregwhitworth> is zcorpan not setup? I didn't see my number popup
  134. # [18:00] <gregwhitworth> I guess it's trackbot
  135. # [18:01] * Joins: Zakim (zakim@public.cloak)
  136. # [18:01] * Joins: RRSAgent (rrsagent@public.cloak)
  137. # [18:01] <RRSAgent> logging to http://www.w3.org/2014/07/30-css-irc
  138. # [18:02] <plinss> zakim, this is style
  139. # [18:02] <Zakim> ok, plinss; that matches Style_CSS FP()12:00PM
  140. # [18:02] <dael> ScribeNick: dael
  141. # [18:02] <Zakim> +??P16
  142. # [18:02] <Zakim> +glenn
  143. # [18:03] <adenilson> Zakim: +??P16 should be me.
  144. # [18:03] <Zakim> +SylvaIng
  145. # [18:03] * Joins: MaRakow (~MaRakow@public.cloak)
  146. # [18:04] <dael> zakim, who is here?
  147. # [18:04] <Zakim> On the phone I see +1.907.315.aaaa, Lea, dael, +1.240.421.aabb, plinss, ??P16, glenn, SylvaIng
  148. # [18:04] <Zakim> On IRC I see MaRakow, RRSAgent, Zakim, AH_Miller, alex_antennahouse, dael, antonp, gregwhitworth, lmclister, Ms2ger, adenilson, dbaron, glenn, Bert, fantasai, ed, mihnea___,
  149. # [18:04] <Zakim> ... darktears, nikos_, birtles, abucur__, amtiskaw_____, dwim, kangil, renoirb, CSSWG_LogBot, shepazu, anssik_, achicu_____, paul___irish, timeless, krijnhoetmer, astearns_,
  150. # [18:04] <Zakim> ... gsnedders, Hixie, TabAtkins, lmclister_____, jacobg______, logbot, alexmog, mvujovic____, slightlyoff, sgalineau, plinss, projector, shans, leaverou, hober, sylvaing,
  151. # [18:04] <Zakim> ... SimonSapin, decadance
  152. # [18:04] <Zakim> +antonp
  153. # [18:04] * plinss changes topic to 'http://lists.w3.org/Archives/Public/www-style/2014Jul/0572.html'
  154. # [18:04] <Zakim> +Stearns
  155. # [18:05] * Joins: bradk (~bradk@public.cloak)
  156. # [18:05] * Joins: bkardell_ (~uid10373@public.cloak)
  157. # [18:05] <Zakim> +[IPcaller]
  158. # [18:05] <Zakim> +[Microsoft]
  159. # [18:05] <Zakim> - +1.907.315.aaaa
  160. # [18:05] <alex_antennahouse> I'm IPCaller
  161. # [18:05] * Joins: Rossen_ (~Rossen@public.cloak)
  162. # [18:05] <MaRakow> Zakim, I'm [Microsoft]
  163. # [18:05] <Zakim> I don't understand 'I'm [Microsoft]', MaRakow
  164. # [18:05] <bkardell_> Phone issues, unable to dial in today.. Sorry, irc only
  165. # [18:05] <Zakim> + +1.603.821.aacc
  166. # [18:05] * Joins: smfr (~smfr@public.cloak)
  167. # [18:05] <Zakim> +BradK
  168. # [18:05] <Zakim> +[IPcaller.a]
  169. # [18:05] <astearns_> zakim, who is noisy?
  170. # [18:05] <MaRakow> Zakim, [Microsoft] is me
  171. # [18:05] <Zakim> +MaRakow; got it
  172. # [18:05] <Zakim> +SteveZ
  173. # [18:06] <Zakim> +dbaron
  174. # [18:06] <Zakim> +??P33
  175. # [18:06] <Zakim> astearns_, listening for 10 seconds I heard sound from the following: 14 (8%), [IPcaller.a] (38%)
  176. # [18:06] <SimonSapin> Zakim, ??P33 is me
  177. # [18:06] <Zakim> +SimonSapin; got it
  178. # [18:06] <dael> zakim, [IPCaller] is alex_antennahouse
  179. # [18:06] <Zakim> +alex_antennahouse; got it
  180. # [18:06] <Zakim> +smfr
  181. # [18:06] <Zakim> +[Microsoft]
  182. # [18:06] <adenilson> Zakim, ??P16 is me.
  183. # [18:06] <Zakim> +adenilson; got it
  184. # [18:06] <Rossen_> zakim, microsoft is me
  185. # [18:06] <Zakim> +Rossen_; got it
  186. # [18:06] * fantasai is on, unsure which
  187. # [18:06] <Zakim> + +1.631.398.aadd
  188. # [18:07] * Joins: SteveZ (~SteveZ@public.cloak)
  189. # [18:08] <dael> plinss: Let's get started
  190. # [18:08] <dael> plinss: Anything to add to the agenda
  191. # [18:08] <dael> plinss: That's a no.
  192. # [18:09] <dael> Topic: Animations Issues
  193. # [18:09] * fantasai had sent a few agenda+ earlier
  194. # [18:09] <dael> sylvaing: This was an old issue about the shorthands and subproperties that aren't available. as dbaron pointed out there's a buncho f subissues that need resolution. At least 2, maybe a 3rd
  195. # [18:10] <dael> sylvaing: The first is that in general the computed value can depend on other computed values. So if you have a font size and set an resolution of 2em, the font size effect that. Do we do that in keyframes
  196. # [18:10] * Joins: smfr_ (~smfr@public.cloak)
  197. # [18:10] <dael> sylvaing: Second is that in other implementations we ignore non-impl properties. So do we apply in a keyframE? If you have border-start: none and set a keyframe, does that reset to 0?
  198. # [18:11] <dael> sylvaing: 3rd is from a resolution a while about. How do we animate non-animatable properties. There my understanding was that it would be animations and transitions, but dbaron says it's only animations.
  199. # [18:11] <dael> sylvaing: dbaron am I missing anything?
  200. # [18:11] <dael> dbaron: There's complications to the second issue, but we can get there at some point.
  201. # [18:11] <Zakim> +hober
  202. # [18:12] * dbaron now wonders if he meant first issue
  203. # [18:12] <dael> sylvaing: So first we have a keyframe anywhere in the animation. ex we have font size of 42px and an indenet of 2em, do we resolve the keyframe as a reg rule applied to the element?
  204. # [18:12] <dael> sylvaing: I think yes. It would be surprising if rule work one way inside a keyframe and different outside
  205. # [18:12] <dael> dbaron: One complication here.
  206. # [18:12] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
  207. # [18:12] <Zakim> + +1.425.463.aaee
  208. # [18:13] <dael> dbaron: The way anmations work is that you animate each prop sep. So if you have 0% prop that spec both prop, but a 50% that's only 2 prop, you animate the first as if it's only 50% and the second from 0% to 100%. One model to treat this is the keyframe is a style rule
  209. # [18:13] <dael> sylvaing: I believe this is what authors think happens
  210. # [18:14] <dael> dbaron: Maybe. It produces weird results in that case. If you're anim font size in em and you're doing something else in em units in the keyframe. You'd do the em units at 0 against 1em and 3 against 3em.
  211. # [18:14] * Joins: tantek (~tantek@public.cloak)
  212. # [18:14] <dael> sylvaing: I don't think it's ness. weird. If you're animating the width of something and the container is changing width, they'llin teract.
  213. # [18:15] * Joins: smfr (~smfr@public.cloak)
  214. # [18:15] <dael> sylvaing: I agree that if you think of animations as each prop in it's own keyframe, then I think current makes sense, but I'm not convinced that's how authors think about it. The keyframes are like a selector. It's a rule with a bunch of prop that aplly together. so it's surprising if font size is 16px and use 2em it's different if you move within a keyframe
  215. # [18:16] <dael> dbaron: Maybe. I'm curious what others think.
  216. # [18:16] <dael> sylvaing: Me too. If folks like leaverou are on the call that would be great.
  217. # [18:16] <dael> smfr_: Anything about how the children of things are being animated?
  218. # [18:16] * Joins: gregwhitworth_ (~gregwhitworth@public.cloak)
  219. # [18:16] <dael> dbaron: Animations do affect the computed value
  220. # [18:16] <dael> smfr_: So it would make sense for em size to be affected by font size.
  221. # [18:16] * tantek notes that children of things tend to be quite animated.
  222. # [18:17] <dael> dbaron: That's not the question. It's em size inside the keyframe itself.
  223. # [18:17] <dael> smfr_: I think that if inheret works I think em size would. I'm not sure I understand the implications of your example.
  224. # [18:17] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
  225. # [18:17] * leaverou LOL tantek
  226. # [18:17] * tantek leaverou :)
  227. # [18:17] <dael> smfr_: It seems when you're doing em size in a 50 keyframe, it seems you would pick half way between 0 and 100
  228. # [18:17] <dael> dbaron: WE need an order to resolve prop dependant cycles in order to resolve animations prop in correct order
  229. # [18:18] <dael> smfr: Isn't that true of style positions anyway?
  230. # [18:18] <dael> dbaron: Maybe. We'd need to explicitly have code to know that in this case. We don't now.
  231. # [18:18] * fantasai is super confused
  232. # [18:18] * leaverou is too
  233. # [18:18] * bkardell_ is also confused
  234. # [18:19] * tantek apologizes for the confusion
  235. # [18:19] <dael> dbaron: I think the model...keyframes are a bit weird because you only use the stuff out of them that was spc in them. Prop not spec in the keyframe aren't overridden by the anmatioin so they're diff from the rest of the cascade
  236. # [18:19] <dael> smfr: So if I animate the font size and have stuff outside in em it's not effected?
  237. # [18:20] <dael> dbaron: That's effect. Keyframes are diff from rest of cascade because it matters what's spec or not that doesn't normally matter. it effect if the animation choose to overide during that period of time
  238. # [18:20] * leaverou Some code showng the issue we're trying to decide about would be useful, since so many here are lost.
  239. # [18:20] * Joins: smfr_ (~smfr@public.cloak)
  240. # [18:20] <dael> dbaron: Esp if you have mlti animations running.
  241. # [18:20] <bkardell_> dbaron: I agree that is weird
  242. # [18:20] <dael> plinss: It looks like there's a lot of people lost. Is there an ex we can put in IRC
  243. # [18:20] <dael> sylvaing: WE can do the one in the thread.
  244. # [18:20] <dael> dbaron: A simple is which.
  245. # [18:20] <sgalineau> #a { animation: a; font-size: 16px; }
  246. # [18:20] <sgalineau> @keyframes a { 0% { font-size: 32px; text-indent: 2em } }
  247. # [18:21] <sgalineau> does the font-size: 32px inside the keyframe change the value of
  248. # [18:21] <sgalineau> text-indent (and make it 64px rather than 32px)?
  249. # [18:21] <dael> Rossen_: So if we have font which is animating at 1/3, let's say 30% from 2em to 1em
  250. # [18:21] <Rossen_> 2 > 1 > 3
  251. # [18:21] <dael> Rossen_: And to the 100% is to 3em. It goes 2 to 1 to 3.
  252. # [18:21] <sgalineau> original thread http://lists.w3.org/Archives/Public/www-style/2014Jul/0297.html
  253. # [18:21] <leaverou> if font-size in the animation supersedes the one in the rule, I'd expect it would also apply to ems. OTherwise it would be super confusing
  254. # [18:21] <dael> Rossen_: And then we have animatable which is in em which goes the opposite and snaps on the 1/3 which is in the middle of the 2 to 1 animation of the font.
  255. # [18:21] <sgalineau> leaverou: right.
  256. # [18:22] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
  257. # [18:22] <dael> Rossen_: So the q is, what would be the resolution at the 30% of the prop that's animating in em if the font is being animated from 2 to 1 in the same time
  258. # [18:22] <dael> Rossen_: dbaron Is that the right rep of your point?
  259. # [18:22] <sgalineau> leaverou: i think authors expect keyframe rules to apply like other rules. in practice, it's as if each prop gets its own @keyframes rule
  260. # [18:22] <dael> dbaron: I didn't follow
  261. # [18:22] <dael> fantasai: Can you type it in CSS code?
  262. # [18:23] * Joins: smfr (~smfr@public.cloak)
  263. # [18:23] <dael> plinss: Are you typing, Rossen_ ?
  264. # [18:23] <dael> Rossen_: Yes.
  265. # [18:23] <bkardell_> sgalineau: FWIW, that is what I would expect as an author :)
  266. # [18:23] <dbaron> @keyframes a { 0% { font-size: 32px; width: 10em } 50% { width: 15em } 100% { font-size: 64px; width: 20em} } #elem { animation: a linear 5s; font-size: 16px }
  267. # [18:23] <dael> dbaron: I'm typing a diff ex as well
  268. # [18:23] * fantasai finds the agenda+ email finally: https://lists.w3.org/Archives/Member/w3c-css-wg/2014JulSep/0058.html
  269. # [18:24] <leaverou> I think if the link between font-size and ems is broken, this is going to be very confusing
  270. # [18:24] * smfr fantasai: agenda is in the /topic
  271. # [18:24] * plinss fantasai: go it
  272. # [18:24] * plinss fantasai: got it
  273. # [18:24] <leaverou> so I'd expect em to animate as the font-size is animating, as well as animating from 2 -> 3
  274. # [18:24] <dael> sylvaing: So in dbaron ex I would expect width to be 120. At 50% the font would be between 32 and 64, 15x48, I guess?
  275. # [18:25] <dael> sylvaing: at 100% 20x64
  276. # [18:25] <dael> dbaron: What about if the animation had 2 running, low afft font, upper affecting width
  277. # [18:25] <dael> fantasai: I think yes. I think at each point in time take the combo of all rules nad interpolate as needed.
  278. # [18:25] <dael> dbaron: That gets really complicated.
  279. # [18:26] <leaverou> dbaron: To understand or to implement?
  280. # [18:26] <dael> sylvaing: What's more complicated for author? Combine them or think as each being split into logical keyframe rules? It gets complicatedi n both directions. It's complex enough, but thinking of each property your animating getting a logical keyframe is a bit
  281. # [18:27] <dbaron> @keyframes a1 { 0% { font-size: 32px } 100% { font-size: 64px } } @keyframes b { 0% { width: 10em } 50% { width: 15em } 100% { width: 20em} } #elem { animation: a linear 5s, b linear 8s; font-size: 16px }
  282. # [18:27] <dael> sylvaing: So we're 25 minutes in. If it needs more email discussion, that's fine. Like TabAtkins I'm in favor of creating keyframe rules like @ rules to min surprizes
  283. # [18:27] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
  284. # [18:27] * leaverou thanks fantasai :)
  285. # [18:27] <dael> fantasai: leaverou asked if it's complicated to understand or impl?
  286. # [18:27] <dael> dbaron: I'm pretty sure it's complicated it implement. I think it's also hard to understand
  287. # [18:27] <dael> fantasai: I think anything else is hard to understand, but I can't speak to impl
  288. # [18:28] <dael> smfr: I think this is a fix for something that isn't encountered much. leaverou case witht eh border shorthand is a more common thing to talk about
  289. # [18:28] <bkardell_> +1, I can't actually see another way that is more intuitive
  290. # [18:28] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
  291. # [18:28] * Joins: darktears (~darktears@public.cloak)
  292. # [18:29] <dael> plinss: Let's see if we can wrap up. Back to dbaron first ex. You're animating font size in first and last, but not middle, but doing width in all. So over the whole animating your changing the font size, so I don't see why the em size isn't changing.
  293. # [18:29] <dael> dbaron: I think current is you apply each rule and you extract values
  294. # [18:29] <leaverou> +1 to plinss
  295. # [18:29] <dael> plinss: So at 50% you're appling the ful the set width, but the other keyframes are still involved
  296. # [18:29] <Rossen_> @keyframes a {0%{font-size: 20px; width: 10em} 33%{ width: 20em } 66%{font-size: 20px;} 100%{font-size: 30px; width: 30em}}
  297. # [18:29] <dael> sylvaing: So then the animtiong, we're not animating computed values
  298. # [18:29] <dael> dbaron: We're doing it, but where and when do computed values come from?
  299. # [18:29] * Joins: smfr_ (~smfr@public.cloak)
  300. # [18:30] <dael> fantasai: I understand better. We have a missing font size in the middle keyframe. One option is to compute from the other keyframes. The other is to take it from the style rule without the animation because in this keyframe we weren't given a value
  301. # [18:31] <dael> dbaron: I don't think it's that simple. You have to decide if the base incl other animations or not. And if you try and inc things from other animations in the base value, you need to consider when and that can make animations jump in odd ways.
  302. # [18:31] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
  303. # [18:31] * smfr_ is now known as smfr
  304. # [18:31] * hober http://sherri9.typepad.com/.a/6a01157142e48a970c01347fef07ac970c-pi
  305. # [18:31] <dael> fantasai: I think the two things that make sense is you interpolate whatever is missing and do your computations from there. Or in a given animation you want to have a value for every prop mentionened and anything missing comes from the unanimated state.
  306. # [18:31] * bkardell_ lolz
  307. # [18:31] <leaverou> IMHO the 2nd option is sure to cause a lot of WTFs…
  308. # [18:32] <dael> fantasai: things that don't take the value from the current state seems confusing.
  309. # [18:32] <dael> sylvaing: So you're saying animations don't influence eachother
  310. # [18:32] <dael> fantasai: Well, we should take all the rules, apply the cascade and do the animations like that.
  311. # [18:33] <dael> sylvaing: So if A is doing font size and B is doing width in em, you're saysing that B is based on the width before anmation, but if width is together with font size, the width is effected during the animation
  312. # [18:33] * dbaron didn't follow what fantasai said
  313. # [18:33] * Joins: shorton (~shorton@public.cloak)
  314. # [18:34] <dael> fantasai: I think that' straightforward to understand. I thinkt he first is better, but if it's not othen used, it's fine. I don't know how to have the animations rules interact in a different way from taking all the values and interpolating. I understand A and B, but you're saying there's other more complex options
  315. # [18:34] * leaverou observes we’ve spent half the call on this item
  316. # [18:34] * sgalineau your observation is ACCURATE
  317. # [18:34] <dael> fantasai: A is take all the rules that apply from all animations at a given time and iterpolate. B is if you have an animation that's missing values from keyframes, grab them from non-animated state.
  318. # [18:34] * Joins: smfr_ (~smfr@public.cloak)
  319. # [18:34] <dael> dbaron: I think there are other options like if you do one at a time from lowest to highest.
  320. # [18:35] <dael> sylvaing: Okay. WE go back to the ML.
  321. # [18:35] * leaverou does not understand how anybody would support B. It's completely unexpected and confusing.
  322. # [18:35] <dael> fantasai: It's nice to have a summary of the options.
  323. # [18:35] * bkardell_ is pretty sure we can spend entire call on this item and still not resolve well
  324. # [18:35] <bradk> If Width is not affected by font-size during the animation, does it jump at the end of the animation?
  325. # [18:35] <dael> sylvaing: One more q. dbaron in your ex what would it request the animation frame to return. If I try and get the use values
  326. # [18:35] <dael> dbaron: That just gets your callback at a certain time
  327. # [18:35] <dael> sylvaing: So would you expect it any different?
  328. # [18:35] <sgalineau> s/sylvaing/Rossen
  329. # [18:36] <dael> rossen: The way you would resolve the callback vs the two animation lines? In your second example.
  330. # [18:36] <dael> dbaron: Okay.
  331. # [18:36] <dael> Rossen_: In it if you req animation as, say 4sec in B, which is about 50%
  332. # [18:36] <dael> Rossen_: What would you expect the use value for width to be?
  333. # [18:37] <dael> dbaron: That's what we're trying to decide. Basic options are if it's based on...
  334. # [18:37] <dael> Rossen_: What would your impl do today?
  335. # [18:37] <dael> dbaron: 15em x 16px
  336. # [18:37] <dael> dbaron: And I think that might be interop
  337. # [18:37] <dbaron> I think
  338. # [18:38] <dael> Rossen_: I wouldn't expect a decision that would conteract too much something that's interop. I think there's content that depends on that.
  339. # [18:38] <leaverou> with that logic, non-animatable properties being dropped from keyframes is also interoperable, but we resolved against it
  340. # [18:38] <dael> plinss: I hear you, but if this is underspec, we may want to fix.
  341. # [18:38] <dael> Rossen_: Sounds fair, but let's not ignore that.
  342. # [18:38] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
  343. # [18:38] <dael> plinss: If everyone is interop, maybe we have to live with it. Can someone write up a straightforward example for the ML?
  344. # [18:39] <dael> sylvaing: I can start a new thread with the options we've discussed and dbaron can exland
  345. # [18:39] <dael> plinss: Did we get to the border issue?
  346. # [18:39] <dael> dbaron: I think the border issue is the same, but involves non-animatiable prop
  347. # [18:39] <dael> dbaron: So this is the border issue simplified.
  348. # [18:39] * Joins: smfr (~smfr@public.cloak)
  349. # [18:39] <dael> Topic: Specifying options for scrollIntoView()
  350. # [18:40] <dael> plinss: Who wants to talk on this one. Do we have TabAtkins?
  351. # [18:40] <dael> fantasai: No.
  352. # [18:40] <dael> dbaron: I might be able to talk on it, but TabAtkins recently responded. Let me see.
  353. # [18:40] * sgalineau animation: computed-value-issue 2100s infinite;
  354. # [18:40] <dael> dbaron: So. There's something in the CSSOM spec that doesn't make sense and we want to impl that thing so we need to have it make sense. I think. Am I changing topic here?
  355. # [18:41] <dael> dbaron: Maybe. This is a slightly different thread. This isn't the one I asked. I'm commenting on the "and related" part, but I don't know we'll get far without TabAtkins and zcorpan
  356. # [18:41] <dael> plinss: Want to come back to it?
  357. # [18:41] <dael> dbaron: I guess, but we'll have something impl before than
  358. # [18:41] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
  359. # [18:41] <dael> plinss: So is there a concrete prop?
  360. # [18:42] <dael> dbaron: There was, but TabAtkins said he doesn't like it, but not on the public list.
  361. # [18:42] <dael> plinss: We'll aim for progress on the ML>
  362. # [18:42] <dael> Topic: Flexbox and Overflow
  363. # [18:42] <dael> plinss: Can we do this without TabAtkins ?
  364. # [18:43] <dael> fantasai: I'm here, but I don't know if I can do it. Basically the issue is that we normally have the overflow, you can't scroll to the start direction, just the end if it overflows. If we're aligning we go to the end side.
  365. # [18:43] <dael> fantasai: So with flex box should that be flex direction relative instead of writing more
  366. # [18:43] <dael> dbaron: And if you use a ??keyword theyr'e the same thing
  367. # [18:43] <dbaron> s/??/*-reverse /
  368. # [18:44] <dael> Rossen_: And writing mode vs flex direction, fantasai hit the point. I agree with TabAtkins that if we're using flex direction as the origin os start and end for flow, what Chrome does today makes sense. If we don't IE and Firefox makes snes. For impl from our point of view it's easy one way or the other, but we have to decide on pref.
  369. # [18:44] * Joins: smfr_ (~smfr@public.cloak)
  370. # [18:45] <dael> fantasai: I think...I'm leaning toward writing mode relative and take into acocunt content alignmenet and scroll in alignment direction. Reverse should be ordering and page should layout as before, but I haven't thought much on it
  371. # [18:45] <dael> Rossen_: That wouldn't help in the overflow case.
  372. # [18:45] <fantasai> s/and take/maybe take/
  373. # [18:45] <dael> Rossen_: So take this to the ML?
  374. # [18:45] <dael> fantasai: I think so.
  375. # [18:46] <dael> Topic: Ruby
  376. # [18:46] <fantasai> There are three issues I would like the CSSWG to review and approve:
  377. # [18:46] <fantasai> 1. Inlinizing rules http://lists.w3.org/Archives/Public/www-style/2014Jul/0028.html
  378. # [18:46] <fantasai> 2. Floats inside ruby http://lists.w3.org/Archives/Public/www-style/2014Jul/0392.html
  379. # [18:46] <dael> fantasai: I sent a mail earlier about 3 issues in Ruby.
  380. # [18:46] <fantasai> 3. Bidi of ruby http://lists.w3.org/Archives/Public/www-style/2014Jul/0191.html
  381. # [18:46] <dael> fantasai: First one is inlinizing.
  382. # [18:46] * smfr_ fantasai we can’t hear you
  383. # [18:46] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
  384. # [18:46] * smfr_ is now known as smfr
  385. # [18:46] <Zakim> -[IPcaller.a]
  386. # [18:46] <fantasai> Issue is inlinizing rules
  387. # [18:46] * trackbot doesn't understand that ISSUE command.
  388. # [18:47] <fantasai> probably someoine can just read that email
  389. # [18:47] * sgalineau confused trackbot is confused
  390. # [18:47] * Rossen_ trackbot, what DO you understand?
  391. # [18:47] <trackbot> Sorry, Rossen_, I don't understand 'trackbot, what DO you understand?'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
  392. # [18:47] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0028.html
  393. # [18:47] <Zakim> +[IPcaller]
  394. # [18:48] <dael> fantasai: So bidi is an inline time and you break between lines so it would be easy for a ruby space to contain a block element but it's bad because you can't break across lines prop. If you stil a block level thing inside a line element, you have split behaviour. But ruby structures are complicated.
  395. # [18:48] <dael> fantasai: So to deal with this, which seems to have no use case, I added a line saying if you have block level, you add it to inline level.
  396. # [18:49] <dael> fantasai: I wanted to check with the WG if that makes sense or if you want to do something different
  397. # [18:49] <fantasai> s/add it/change its computed display type/
  398. # [18:49] <dael> plinss: For Ruby that makes snese to me. Any other opinions?
  399. # [18:49] <dael> plinss: I guess not.
  400. # [18:50] <dael> fantasai: Related, If you have in your annotation a forced line break char. the white space automatically gets collapsed bc/ I didn't know what to do to linebreak the annotation, but not hte whitespace. I can revist that if there's a more useful behaviour
  401. # [18:50] * Joins: smfr_ (~smfr@public.cloak)
  402. # [18:50] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0392.html
  403. # [18:50] <dael> fantasai: The next issue was floats inside ruby. One option is they go, pass up to the containing block. Or we ignore float.
  404. # [18:51] <dael> fantasai: TabAtkins pref the first. The goal is to make them as much like inlines as practical.
  405. # [18:51] <dbaron> I think it makes sense to pass them up to the containing block.
  406. # [18:51] <dael> SteveZ: Floats as an alignment issue. it says it can't be before the first thing. Would that make s difference in this case?
  407. # [18:51] <dael> fantasai: I'm not sure. It would be aligned to the linebox. It shouldn't be higher than top of line box, right?
  408. # [18:51] <dael> dbaron: Yes.
  409. # [18:51] <dael> SteveZ: Cool.
  410. # [18:52] <dael> RESOLVED: Floats are passed up through Roby to the containing block
  411. # [18:52] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0191.html
  412. # [18:52] <dael> s/Roby/Ruby
  413. # [18:52] <dael> fantasai: Next is bidi. There are two constraints from ruby. They need to be contiguous. Ruby anotations must stay with this bases.
  414. # [18:53] * leaverou thought s/a/b substitutions don't work without final slash. Has this been fixed?
  415. # [18:53] <dael> fantasai: Simmiplist is to force bidi isolation which means they can't be split up. The rule for ordering is use the direction prop of their container.
  416. # [18:53] <dael> fantasai: Is there any comments? Want to think more? Does that seem fine?
  417. # [18:53] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
  418. # [18:53] <dael> plinss: Anyone?
  419. # [18:53] <fantasai> http://dev.w3.org/csswg/css-ruby/#bidi
  420. # [18:54] <dael> SteveZ: If I wanted to split I can break Ruby into chunks?
  421. # [18:54] <dael> fantasai: Yeah.
  422. # [18:54] <dael> dbaron: Does bidi use the direction of the prop? Is there direction associated?
  423. # [18:54] <dael> fantasai: Yes. If you are doing odd things in Ruby with bidi and you're not tagging with correct dir attr things won't look good
  424. # [18:55] <dael> dbaron: But only if you're mixes inside Ruby.
  425. # [18:55] <dael> fantasai: Basically, if the Ruby element doesn't match the element, it'll go bad.
  426. # [18:55] * Joins: smfr (~smfr@public.cloak)
  427. # [18:55] <dael> SteveZ: So if you're annotating Latin with Arabic, I should be careful?
  428. # [18:55] <dael> fantasai: Yeah. I think that's reasonable. I think you'd need to tag tht even if it wasn't Ruby.
  429. # [18:55] <dael> plinss: Okay.
  430. # [18:56] <dael> plinss: Anything else on Ruby?
  431. # [18:56] <dael> fantasai: Re-wrote whitespace handling. No one was interested on the list. If people want time, that's fine, but I think we need a new WD
  432. # [18:56] <dael> Rossen_: Yes, we do.
  433. # [18:56] <dael> plinss: before a new WD?
  434. # [18:56] <dael> Rossen_: No. You can do a new WD
  435. # [18:56] <dael> plinss: This is just a standard pub of a new WD?
  436. # [18:57] <dael> fantasai: Yep. No where near a LC.
  437. # [18:57] <dael> plinss: So any obj to a WD?
  438. # [18:57] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
  439. # [18:57] <dael> RESOLVED: New WD for Ruby
  440. # [18:57] <dael> fantasai: Can a staff contact help me with that tomorrow, or all they all off?
  441. # [18:57] <dael> fantasai: Okay. I'll send it to Sheppard.
  442. # [18:57] <dael> plinss: You might CC Bert.
  443. # [18:57] <Zakim> - +1.425.463.aaee
  444. # [18:57] <dael> fantasai: Okay. Thanks.
  445. # [18:57] <dael> Topic: Renaiming gray()
  446. # [18:57] * fantasai nice. Good timebox
  447. # [18:58] * sgalineau fifty-shades()
  448. # [18:58] * Rossen_ it is fitty-shades()
  449. # [18:58] * fantasai is pretty sure CSS percentages allow for more than fifty shades
  450. # [18:58] <dael> leaverou: The thing is in CSS level 4 there's gray() that goes from 0 to 100% which is black to white. I suggested it should rename to white or black since it's strange that gray(100%) is white.
  451. # [18:58] <leaverou> http://lea.verou.me/2014/07/an-easy-notation-for-grayscale-colors/
  452. # [18:58] <leaverou> https://docs.google.com/forms/d/1pp3RY-A4MAs7b-gmqFx6bKn52_G_WLoPFkV0vueiWP4/viewanalytics
  453. # [18:59] * Joins: rhauck (~rhauck@public.cloak)
  454. # [18:59] <dael> leaverou: I also posted a poll (above) with 246 responces and surprisingly mostly people wanted rgb() with 1 arg or rgba() with 2 arg.
  455. # [18:59] <dael> leaverou: It seems that was concensus, which I find strange since the others are more understandable, but this is what authors liked.
  456. # [18:59] <leaverou> https://docs.google.com/spreadsheets/d/1XJU1jOLb-6ifvkUqK1Y_bsHx9r09aWApce18SkWryFc/edit#gid=166170944
  457. # [18:59] <dael> leaverou: If you want details, they'r ein the spreadsheet above
  458. # [18:59] * Joins: smfr_ (~smfr@public.cloak)
  459. # [19:00] <dael> leaverou: There's a lot of other because originally there was rgb() with 1 or 2 arguements, but I changed it so those votes became other. If you count the other votes, it's even larger.
  460. # [19:00] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  461. # [19:00] * Joins: lmcliste_ (~lmclister@public.cloak)
  462. # [19:00] <dael> plinss: It does follow our pattern of repeating missing arguements.
  463. # [19:01] <dael> ???: I also like the rgb/rgba(). It looks more familair.
  464. # [19:01] <MaRakow> s/???/MaRakow
  465. # [19:01] <dael> SteveZ: There question is would they expect it for the other color fucntions? That's more difficult
  466. # [19:01] * Parts: shorton (~shorton@public.cloak) (shorton)
  467. # [19:01] <dael> SteveZ: If I do different colors than rgb, would they still want one element in the gray direction
  468. # [19:01] * sgalineau on the other hand, shorter # values and shorter rgb() values will do different things? not sure if that matters.
  469. # [19:01] <Zakim> - +1.603.821.aacc
  470. # [19:01] * fantasai notes the spreadsheet is locked
  471. # [19:02] <dael> leaverou: I'm not sure. Like a sort with one arguement? I saw one comment, but only that.
  472. # [19:02] * MaRakow #7 == #777 == #777777 ?
  473. # [19:02] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
  474. # [19:02] <leaverou> s/Like a sort/Like hsl()/
  475. # [19:02] <dael> fantasai: I think that makes sense. The rgb to get gray you write 50% three times and you're short handing. For HSL gray isn't 50% x3. I think it makes sense for RGB, but not HSL.
  476. # [19:02] <dael> SteveZ: There's where I was coming from. I can see people asking for it.
  477. # [19:03] <dael> leaverou: Many suggested what MaRakow suggested which is repeated single digit text values.
  478. # [19:03] * fantasai can't remember why we rejected 2-digit hex
  479. # [19:03] <dael> SteveZ: It certainly makes sense, I was worried we're doing a precedent.
  480. # [19:03] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
  481. # [19:03] * Joins: liam (liam@public.cloak)
  482. # [19:03] <TabAtkins> No way to add alpha
  483. # [19:03] * Joins: lmclister (~lmclister@public.cloak)
  484. # [19:03] <dael> leaverou: In HSL arguements aren't repeated so it's not the same pattern. HSL 50, 50, 50 means nothing.
  485. # [19:03] <dael> SteveZ: I understand.
  486. # [19:03] * MaRakow #78 == #7778 == #77777788?
  487. # [19:03] <fantasai> TabAtkins: 4-digit hex ?
  488. # [19:04] <dael> plinss: So I'm not hearing obj to adopting rgb()/rgba()
  489. # [19:04] <dael> ??: I think that's useful for existing authors, but for new people it's not intutive.
  490. # [19:04] <TabAtkins> Right, no way to do gray hex with alpha.
  491. # [19:04] * Rossen_ #78 == #7788 == #777888 :)
  492. # [19:04] <TabAtkins> 4 digit hex is adjust rgba
  493. # [19:04] <dael> ??: I'm wondering if we could have black with one arguement that's an alias. Are we restircted to picking one?
  494. # [19:04] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
  495. # [19:04] <fantasai> TabAtkins, ????
  496. # [19:04] * Joins: smfr (~smfr@public.cloak)
  497. # [19:04] <dael> leaverou: I agree. I think rgb is the least readable.
  498. # [19:05] * hober http://www.paperlinks.org/wp-content/uploads/2014/02/maybe.gif
  499. # [19:05] <dael> MaRakow: I think they're seeing it as an abbv of what they've been doing for gray. It's not the most readable.
  500. # [19:05] * fantasai thinks ?? has a good point
  501. # [19:05] * fantasai isn't sure who ?? is tho
  502. # [19:05] <dael> leaverou: Any reason we can't have both?
  503. # [19:05] * fantasai :)
  504. # [19:05] <MaRakow> s/MaRakow/???
  505. # [19:05] <dael> plinss: Black wouldn't be b/c it's the opposite, but white.
  506. # [19:05] <dael> leaverou: Black got the second most votes.
  507. # [19:05] * fantasai thinks we need ranked choice here, if we didn't have gray, would those ppl vote white or black?
  508. # [19:06] <dael> ??: I think with black it's the opposite of RGB. If you're doing 255 you'd expect the opposite.
  509. # [19:06] <dael> plinss: I wouldn't want opposite directions.
  510. # [19:06] <dael> plinss: So I think we expect single values for rgb and 2 for rgba.
  511. # [19:06] <dael> ??: Maybe for black and white we accept only single values.
  512. # [19:06] * fantasai too bad choosing the right answer here wasn't black & white :)
  513. # [19:06] <dael> leaverou: If we do black, would that be aspecial value for print?
  514. # [19:06] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
  515. # [19:07] <dael> plinss: I think colors would need to be in the same space unless we're spec doing print.
  516. # [19:07] * sgalineau if you give people enough options it turns out they might choose something weird
  517. # [19:07] <Zakim> -hober
  518. # [19:07] * Quits: gregwhitworth_ (~gregwhitworth@public.cloak) ("Page closed")
  519. # [19:07] <dael> s/??/bkardell
  520. # [19:07] <Zakim> -SylvaIng
  521. # [19:07] <dbaron> s/bkardell/BradKemper/
  522. # [19:07] * Joins: bradk (~bradk@public.cloak)
  523. # [19:07] <Zakim> -SteveZ
  524. # [19:07] <Zakim> -adenilson
  525. # [19:07] <Zakim> -dbaron
  526. # [19:07] <dael> RESOLVED: accept rgb() with single values and rgba() with 2 values and keep exploring other values
  527. # [19:07] <Zakim> -smfr
  528. # [19:07] <Zakim> -BradK
  529. # [19:07] <Zakim> -antonp
  530. # [19:07] <Zakim> -SimonSapin
  531. # [19:07] <Zakim> - +1.240.421.aabb
  532. # [19:07] <Zakim> -Lea
  533. # [19:07] <Zakim> -Rossen_
  534. # [19:07] <dael> plinss: Thanks everyone.
  535. # [19:07] <Zakim> -plinss
  536. # [19:07] * Quits: alex_antennahouse (~458c94ae@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  537. # [19:07] * Quits: AH_Miller (~mike@public.cloak) ("")
  538. # [19:08] <Zakim> -Stearns
  539. # [19:08] <Zakim> -alex_antennahouse
  540. # [19:08] * Joins: AH_Miller (~mike@public.cloak)
  541. # [19:08] <Zakim> -MaRakow
  542. # [19:08] <Zakim> - +1.631.398.aadd
  543. # [19:08] <Zakim> -[IPcaller]
  544. # [19:08] * leaverou sgalineau: In my brief tenure as a graphic designer, I noticed that clients always voted for the worst of the logos they were presented with :P
  545. # [19:08] <Zakim> -dael
  546. # [19:08] * Quits: AH_Miller (~mike@public.cloak) ("")
  547. # [19:08] <sgalineau> leaverou: in my tenure as a US resident following primary elections, I noticed the craziest often wins
  548. # [19:08] * Quits: dael (~dael@public.cloak) ("Page closed")
  549. # [19:08] * Parts: bradk (~bradk@public.cloak) (bradk)
  550. # [19:09] <MaRakow> Actually thinking more, probably #78 == #787878 would make more sense, rather than #77777788
  551. # [19:09] <MaRakow> maybe
  552. # [19:09] <fantasai> yes
  553. # [19:09] <fantasai> The double digit should be a unit imo
  554. # [19:09] <leaverou> MaRakow: the reasoning against these was that #xyz expands by digit, not by repetition
  555. # [19:09] <leaverou> so inconsistency
  556. # [19:10] <fantasai> it's 3 values, it kinda has to
  557. # [19:10] <SimonSapin> leaverou, http://www.commitstrip.com/en/page/16/ ?
  558. # [19:10] <fantasai> repeating wouldn't make any logical sense
  559. # [19:10] <fantasai> hm
  560. # [19:11] <MaRakow> yeah, i'm just thinking out loud. haven't really looked at this before
  561. # [19:11] * fantasai neither, really..
  562. # [19:11] <leaverou> since the call ended and people are still here
  563. # [19:11] <leaverou> I was wondering…
  564. # [19:11] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
  565. # [19:12] <leaverou> is my proposal about numbers with a decimal point but no digits after it completely crazy at this point?
  566. # [19:12] * fantasai whic?
  567. # [19:12] <Zakim> -glenn
  568. # [19:12] <Zakim> Style_CSS FP()12:00PM has ended
  569. # [19:12] <Zakim> Attendees were +1.907.315.aaaa, Lea, dael, +1.240.421.aabb, plinss, glenn, SylvaIng, antonp, Stearns, +1.603.821.aacc, BradK, MaRakow, SteveZ, dbaron, SimonSapin,
  570. # [19:12] <Zakim> ... alex_antennahouse, smfr, adenilson, Rossen_, +1.631.398.aadd, hober, +1.425.463.aaee, [IPcaller]
  571. # [19:13] <glenn> rssagent, publish minutes
  572. # [19:13] <leaverou> fantasai: this: http://lists.w3.org/Archives/Public/www-style/2014Jul/0568.html
  573. # [19:13] <hober> I think we should just keep it as gray()
  574. # [19:13] <glenn> +1
  575. # [19:13] <antonp> grayshade
  576. # [19:13] <hober> see e.g. Core Graphics' CGColorCreateGenericGray()
  577. # [19:13] <antonp> or something similar
  578. # [19:13] <hober> CGColorRef CGColorCreateGenericGray (CGFloat gray, CGFloat alpha);
  579. # [19:14] <fantasai> gray(100%) is black?
  580. # [19:14] <leaverou> it's white
  581. # [19:14] <fantasai> oh
  582. # [19:14] <fantasai> ~_~
  583. # [19:14] <antonp> haha that's gonna confuse me a ton
  584. # [19:14] <leaverou> gray(0%) is black
  585. # [19:14] <fantasai> I know! Do a poll
  586. # [19:14] <leaverou> lol
  587. # [19:14] <fantasai> On your first instinct, gray(100%) is a) black b) white
  588. # [19:15] <fantasai> If you get 90% answers on one answer, go with gray()
  589. # [19:15] <fantasai> otherwise, I think it can be considered a failure
  590. # [19:15] <fantasai> and you have to reject it and find a different name
  591. # [19:15] <MaRakow> no strong opinion re: full stop after numbers. the author will still see a "jump" when editing the number in your example, 2.5 -> 2.0 -> 2.9, but i suppose that's probably a smoother transition than 2.5 -> invalid -> 2.9
  592. # [19:15] <leaverou> MaRakow: See my next post
  593. # [19:16] <leaverou> MaRakow: I got the numbers wrong in that example, exactly because of that reason
  594. # [19:16] <fantasai> leaverou: Two comments
  595. # [19:17] <fantasai> 1. I have no opinion of my own, but I would stand behind whatever dbaron concludes on the issue
  596. # [19:17] <MaRakow> 2 -> 2.1 is a special case though -- this won't work so well for any other tenth edit, e.g. 2.8->2.9
  597. # [19:17] <fantasai> 2. might be possible for the tools to work around this
  598. # [19:17] <leaverou> MaRakow: It's basically any integer to any decimal value, not only to .1
  599. # [19:17] <SimonSapin> fantasai: "On your first instinct, gray(100%) is a) black b) white", that could include c) "medium" gray
  600. # [19:18] <fantasai> Also, 2.9->3.0 is going to break in any case
  601. # [19:18] <hober> yeah, obviously gray(100%) is the grayest gray :)
  602. # [19:18] <leaverou> fantasai: Yes, sometimes they do. E.g. dev tools usually support arrows to increment/decrement smoothly. But we can't depend on that
  603. # [19:18] <MaRakow> i see. also agree this seems like something tools could solve
  604. # [19:18] <liam> gray in colour is a shade rather than a tint usually, so 0% would be white
  605. # [19:18] <fantasai> SimonSapin: an interesting point, but I think that makes it awkward to have the range 0%-200%
  606. # [19:19] <SimonSapin> fantasai: of course. Which is why gray() doesn’t work IMO
  607. # [19:19] <leaverou> still, it's fewer cases of breakage, for not much cost (unless I’m missing something) and I don't see how it could break existing code. In fact, it's 1 char less lookahead for the grammar
  608. # [19:19] <astearns_> leaverou: I expect the proper place to fix your 1. issue is just in the tools
  609. # [19:20] <astearns_> I don't see a benefit to allowing 1.px in a stylesheet
  610. # [19:20] <leaverou> this argument be used against against ANY syntax improvement
  611. # [19:20] <leaverou> s/be/could be
  612. # [19:20] <astearns_> I see it more of an affordance than an improvement
  613. # [19:21] <leaverou> it's also consistency with the other OWP technologies. JS allows it
  614. # [19:22] * fantasai prefers black to white as well, fwiw
  615. # [19:23] <liam> gray(200%) should be blue with pink stripes. Keep the b*stards guessing. Better is black(50%)
  616. # [19:23] <liam> always knew you were really a goth :)
  617. # [19:24] <leaverou> I would love black() even more if it also corresponded to device-cmyk(0,0,0,x) in print. Currently, I think printers convert RGB grays to use all the inks, which is super wasteful.
  618. # [19:24] <liam> depends on the printer driver / RIP
  619. # [19:25] <liam> some can do UCR too, and some not.
  620. # [19:25] <leaverou> cheap home printers?
  621. # [19:26] <SimonSapin> I don’t think it’s CSS’s job (in a feature not related to printing) to work around cheap printers being stupid
  622. # [19:27] <SimonSapin> would it make sense to have both white() and black(), even though they’re technically redundant?
  623. # [19:28] <leaverou> IIRC device-cmyk() is converted to rgb with the naïve conversion anyway, which I believe would convert grayscale colors to proper RGB grays. So we could define black() as a shortcut to device-cmyk(0,0,0,x). But then there’s no opacity… :(
  624. # [19:29] <SimonSapin> should we have device-cmyka() too?
  625. # [19:29] <leaverou> SimonSapin: Let’s turn all the CSS colors into functions!!!1!1 :P
  626. # [19:29] <fantasai> device-cmyk(0,0,0,50%) is not 50% opaque?
  627. # [19:30] <leaverou> fantasai: Not unless we implement some form of overprint
  628. # [19:30] <leaverou> (which btw, is sorely needed)
  629. # [19:30] * fantasai doesn't really understnad how device-cmyk() is supposed to work
  630. # [19:31] <leaverou> it's just a different color space. 50%K is not semi-transparent, just like rgb(50%,0,0) isn't
  631. # [19:31] <liam> k is black, not opacity
  632. # [19:31] <SimonSapin> does alpha blending make sense in cmyk space?
  633. # [19:32] <fantasai> I know, but if you're spilling black at 50% of its disperal, is it opaque?
  634. # [19:32] <leaverou> SimonSapin: Why not? InDesign/Illustrator support it…
  635. # [19:32] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
  636. # [19:32] <fantasai> Like, 50% black on orange paper is somewhat orange, is it not
  637. # [19:33] <fantasai> if you printed orange ink under it, that would be the same, no?
  638. # [19:33] * fantasai is taking device-cmyk too literally
  639. # [19:33] <leaverou> fantasai: If you overlay a 50% K div over an orange div, it wouldn't be affected unless you overprint
  640. # [19:33] <leaverou> and there's no standard way of overprinting right now AFAIK
  641. # [19:34] <leaverou> in practice, whwat would happen
  642. # [19:34] <leaverou> is that the print formatter would create a "hole" in the orange div
  643. # [19:34] <leaverou> and print the gray on top of it
  644. # [19:34] <leaverou> you can see that a lot in magazines and stuff
  645. # [19:34] <leaverou> when the designer forgot to overprint
  646. # [19:34] <leaverou> and the letters aren't completely aligned
  647. # [19:35] <leaverou> (because perfect alignment is rare)
  648. # [19:35] <leaverou> and you can see the white "hole" underneath them
  649. # [19:36] <leaverou> fantasai: ^^
  650. # [19:36] * fantasai nods
  651. # [19:38] <leaverou> fantasai: Does it make sense?
  652. # [19:38] <fantasai> yes
  653. # [19:38] <fantasai> I'm aware :)
  654. # [19:38] <liam> 50% black on orange paper will show up as a pattern of tiny dots usually, like newsprint
  655. # [19:38] <liam> (or on any other colour paper)
  656. # [19:40] <leaverou> I believe print formatters implement their own proprietary overprint properties, or nothing at all (not sure about AH, but I believe Prince has a property for it)
  657. # [19:40] <liam> printing inks used for commercial offset litho (the basis for CMYK) are opaque at around 80% depending on dot gain (how absorbent the paper is) but lower values are simulated by dots, and the lower colours show though the dots. Black is printed underneath.
  658. # [19:40] <liam> well, you also need trapping support (avoiding sharp corners), and support for avoiding too much ink at any pixel
  659. # [19:41] <liam> four-colour separation software may do some of that, and/or "preflight" software.
  660. # [19:49] * Joins: glenn_ (~gadams@public.cloak)
  661. # [19:53] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  662. # [19:55] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  663. # [19:55] * Joins: lmclister (~lmclister@public.cloak)
  664. # [20:04] * Joins: glenn (~gadams@public.cloak)
  665. # [20:07] * Joins: glenn__ (~gadams@public.cloak)
  666. # [20:09] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  667. # [20:10] * Zakim excuses himself; his presence no longer seems to be needed
  668. # [20:10] * Parts: Zakim (zakim@public.cloak) (Zakim)
  669. # [20:11] * Joins: glenn_ (~gadams@public.cloak)
  670. # [20:11] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  671. # [20:13] * Joins: glenn (~gadams@public.cloak)
  672. # [20:15] * Quits: glenn__ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  673. # [20:18] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  674. # [20:20] * Joins: glenn_ (~gadams@public.cloak)
  675. # [20:23] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  676. # [20:28] <fantasai> shepazu: would you be the W3C Staff shepherd of a CSS Ruby publication for me, please?
  677. # [20:30] * Joins: glenn (~gadams@public.cloak)
  678. # [20:33] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  679. # [20:35] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  680. # [20:36] * Joins: lmclister (~lmclister@public.cloak)
  681. # [20:45] * Quits: SteveZ (~SteveZ@public.cloak) ("Page closed")
  682. # [20:54] * Joins: glenn_ (~gadams@public.cloak)
  683. # [20:58] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
  684. # [20:58] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
  685. # [20:59] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  686. # [20:59] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  687. # [21:09] * leaverou is now known as leaverou_away
  688. # [21:10] * Joins: Ms2ger (~Ms2ger@public.cloak)
  689. # [21:22] * Joins: glenn (~gadams@public.cloak)
  690. # [21:24] <fantasai> krit: I'm guessing you meant text-indent rather than atext-indent?
  691. # [21:24] <fantasai> https://dvcs.w3.org/hg/csswg/annotate/109c35c788f1/default.css#l113
  692. # [21:24] * fantasai about to fix that
  693. # [21:25] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  694. # [21:31] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  695. # [21:32] * Joins: lmclister (~lmclister@public.cloak)
  696. # [21:32] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  697. # [21:32] * Joins: lmclister (~lmclister@public.cloak)
  698. # [21:34] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
  699. # [21:35] <krit> fantasai: not “a text-ident”? After linear-gradient at? :)
  700. # [21:35] <krit> fantasai: typo :)
  701. # [21:37] <fantasai> TabAtkins: Bikeshed seems to slurp up rather more issue than it should for <span class=issue> inside a paragraph.
  702. # [21:37] * fantasai getting random text from the next line
  703. # [21:38] <fantasai> into the issue index
  704. # [21:46] * Joins: glenn_ (~gadams@public.cloak)
  705. # [21:51] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
  706. # [22:04] * Joins: rhauck1 (~rhauck@public.cloak)
  707. # [22:05] * Joins: rhauck2 (~rhauck@public.cloak)
  708. # [22:05] * Quits: rhauck1 (~rhauck@public.cloak) (Client closed connection)
  709. # [22:09] * Quits: rhauck (~rhauck@public.cloak) (Ping timeout: 180 seconds)
  710. # [22:12] * Joins: lmcliste_ (~lmclister@public.cloak)
  711. # [22:12] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  712. # [22:20] * fantasai wonders if webreq is on vacation, too
  713. # [22:25] <astearns_> fantasai: there's a publishing moratorium until Friday
  714. # [22:27] * Joins: dbaron (~dbaron@public.cloak)
  715. # [22:30] <fantasai> astearns_: Ah. Thanks :)
  716. # [22:36] <shepazu> fantasai, I'll start it, and let Chris or Bert take over as they are available
  717. # [22:36] <shepazu> fantasai, do you already have approval for publication tomorrow?
  718. # [22:41] <fantasai> No, apparantly there's a moratorium, so it'd have to be Tuesday?
  719. # [22:58] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
  720. # [22:58] * Joins: rhauck (~rhauck@public.cloak)
  721. # [22:58] * Quits: rhauck2 (~rhauck@public.cloak) (Client closed connection)
  722. # [22:59] * Joins: lmclister (~lmclister@public.cloak)
  723. # [22:59] * Joins: rhauck1 (~rhauck@public.cloak)
  724. # [22:59] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  725. # [22:59] * Quits: rhauck (~rhauck@public.cloak) (Client closed connection)
  726. # [22:59] <shepazu> fantasai, ready to go on Tuesday
  727. # [22:59] * Joins: lmclister (~lmclister@public.cloak)
  728. # [23:00] <shepazu> I put it in place, did a bit of cleanup (see email), and Denis will push it out on Ruby Tuesday
  729. # [23:01] <Ms2ger> Isn't it funny how this still hasn't been automated?
  730. # [23:05] <fantasai> shepazu: Thanks!
  731. # [23:05] * fantasai supposes shepazu is right, Ruby should be published on Tuesdays.
  732. # [23:06] <fantasai> Ms2ger: W3C's computer systems are antiquated.
  733. # [23:06] <fantasai> Ms2ger: Ironic, given we're defining the bleeding edge of the web platform
  734. # [23:06] <SimonSapin> fantasai: every Tuesday? :)
  735. # [23:06] <fantasai> lol
  736. # [23:06] <fantasai> No, just once in a Blue Moon
  737. # [23:07] <Ms2ger> fantasai, that hasn't been W3C for a decade ;)
  738. # [23:07] <fantasai> It has for CSS!
  739. # [23:07] * fantasai wishes text justification bled less
  740. # [23:08] <Ms2ger> Perhaps I should avoid snarky comments about the CSSWG in this channel :)
  741. # [23:10] * fantasai not really sure what you're commenting on
  742. # [23:10] <Ms2ger> Nothing
  743. # [23:11] <Ms2ger> But I could be commenting on the general speed of the WG, say
  744. # [23:11] <Ms2ger> But not tonight
  745. # [23:12] * Ms2ger yawns
  746. # [23:12] <fantasai> Hm, I think you misunderstand the phrase then.
  747. # [23:12] <fantasai> It's nothing to do with speed.
  748. # [23:12] <Ms2ger> No, I understand
  749. # [23:12] <Ms2ger> I just like complaining :)
  750. # [23:12] <fantasai> heh
  751. # [23:12] <fantasai> you're in a channel of spec writers
  752. # [23:12] <fantasai> if you're being imprecise with words, it will be noted =)
  753. # [23:13] <Ms2ger> And hey, "antiquated" makes me think of the CSSWG, I can't help it ;)
  754. # [23:13] * Ms2ger poofs
  755. # [23:13] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  756. # [23:13] <fantasai> TabAtkins, krit: Just redid the styling for inline notes, thoughts?
  757. # [23:14] <fantasai> http://dev.w3.org/csswg/css-flexbox/#cross-sizing
  758. # [23:14] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  759. # [23:14] * Joins: lmclister (~lmclister@public.cloak)
  760. # [23:14] <fantasai> TabAtkins: This one's less intrusive, so you can read the rest of the paragraph without having the note (which should be de-emphasized, if anything) jump at you
  761. # [23:15] <fantasai> Ms2ger: Yeah, we're survivors from an older era.
  762. # [23:15] <fantasai> The era before bug-tracking systems maybe
  763. # [23:19] * leaverou_away is now known as leaverou
  764. # [23:23] <TabAtkins> device-cmyk() has an optional alpha argument
  765. # [23:23] * Joins: glenn (~gadams@public.cloak)
  766. # [23:23] <leaverou> TabAtkins: really?!
  767. # [23:25] <TabAtkins> Go read the spec!
  768. # [23:25] <leaverou> lol, obviously :P It was an expression of surprise
  769. # [23:28] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
  770. # [23:29] * Joins: rhauck (~rhauck@public.cloak)
  771. # [23:29] * Quits: rhauck1 (~rhauck@public.cloak) (Client closed connection)
  772. # [23:34] * Joins: jcraig (~jcraig@public.cloak)
  773. # [23:37] <TabAtkins> fantasai: No, I can't really read that. Green colorblind, yo.
  774. # [23:37] <TabAtkins> It looks too similar to the black text.
  775. # [23:38] <TabAtkins> fantasai: Also, example of it messing up on inline issues?
  776. # [23:38] <TabAtkins> I bet I know what the problem is.
  777. # [23:39] <TabAtkins> (It's lxml's stupid data model, which is dumb and I hate it.)
  778. # Session Close: Thu Jul 31 00:00:00 2014

The end :)