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

Options:

1. # Session Start: Tue Mar 30 00:00:00 2010
2. # Session Ident: #css
3. # [00:00] <fantasai> glazou: If solving this for w3.org involves more work for us on the test suite, let's just move.
4. # [00:00] <fantasai> glazou: I suggest we do nothing and wait
5. # [00:01] <fantasai> bert: I also have an action to get the issues list onto w3c servers
6. # [00:02] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
7. # [00:02] * Joins: dbaron (dbaron@63.245.220.11)
8. # [00:02] <fantasai> Chris: The SVGWG had its working its files off-site on a company server, then that company got bought and the files disappeared. TOok months to get the tar files back.
9. # [00:03] <fantasai> fantasai, plinss: Our server is not controlled by a company, it's a personal account, funded by HP, but under plinss's name
10. # [00:04] <fantasai> fantasai: We could create tarballs for the snapshots, just publish the latest expanded out
11. # [00:05] <fantasai> Topic: Reviewing testcases
12. # [00:05] <fantasai> Arron: We're not getting a lot of traction on review of testcases
13. # [00:05] <fantasai> Arron: It's something that needs to happen
14. # [00:06] <fantasai> Plinss: We decided we'd drive reviews by people generating implementation reports
15. # [00:06] <fantasai> plinss: And then people can object if they find test is wrong
16. # [00:07] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
17. # [00:08] <fantasai> glazou: When will the test suite be complete?
18. # [00:09] <fantasai> discussion between glazou and fantasai about scheduling test suite work
19. # [00:10] <fantasai> fantasai aims to publish ts beta 1 in mid-April
20. # [00:10] <fantasai> Arron: It should take each browser vendors 2 days of 8 hours each to run an implementation report
21. # [00:11] <fantasai> Glazou: We must be in PR by September, keep that in mind
22. # [00:11] <fantasai> Topic: Vendor prefixes
23. # [00:11] <fantasai> Bert: Why?
24. # [00:11] <fantasai> glazou: There's been a bunch of discussion on www-style
25. # [00:11] <fantasai> glazou: I don't think the current situation is satisfactory from the web authors pov
26. # [00:12] <fantasai> glazou: On filters and web-authoring tools side it's hell
27. # [00:12] <fantasai> Alex: Shouldn't be using experimental stuff until it's stable
28. # [00:13] <fantasai> dbaron: I think we should be able to find a way to declare things stable until CR
29. # [00:13] <fantasai> Steve: There is a way. It's called CR. It hasn't received enough review until then
30. # [00:13] <fantasai> It hasn't gone to last call
31. # [00:14] <TabAtkins> @mixin border-radius(radius: 8px) {
32. # [00:14] <TabAtkins> -moz-border-radius: var(radius);
33. # [00:14] <TabAtkins> -webkit-border-radius: var(radius);
34. # [00:14] <TabAtkins> border-radius: var(radius);
35. # [00:14] <fantasai> Steve: If you need to, make smaller modules.
36. # [00:14] <TabAtkins> }
37. # [00:14] <TabAtkins> .box-with-corners {
38. # [00:14] <TabAtkins> @mixin border-radius(12px);
39. # [00:14] <TabAtkins> border: 2px solid black;
40. # [00:14] <TabAtkins> }
41. # [00:14] <TabAtkins> ^^^ make an end-run around the issue with additions to syntax
42. # [00:14] <fantasai> glazou: I think we should have a frozen status for features
43. # [00:15] <fantasai> Steve: ... W3C process
44. # [00:15] <fantasai> dbaron: The versioning process of CSS isnt' a W3C process issue
45. # [00:15] <fantasai> anne: What impl do or not doesn't have anything to do with process
46. # [00:16] <fantasai> Steve: You should be at CR when you write the tests because that's when the spec is stable enough to write a test suite
47. # [00:17] * Joins: dbaron (dbaron@63.245.220.11)
48. # [00:17] <fantasai> Steve: We have good examples where removing the prefix would have been a mistake
49. # [00:17] <fantasai> Howcome: We have had decisions in the past, when we said they will never change again, even though they're not in CR. I think that makes sense
50. # [00:18] <fantasai> Steve: The reason it doesn't make sense is that part of Last Call, which is the part you're living out, is to get review from people /not/ in the WG. And you're not getting that review
51. # [00:18] <fantasai> Tab: I agree with Steve. I think we should stick with this model.
52. # [00:18] <fantasai> Bert: The problem is we do so many things simultaneously. We should focus on things that are stable and /finish/ them. Then we wouldn't have this problem.
53. # [00:19] <fantasai> Tab: We could make vendor-prefixes less painful for authors we could use a mixins syntax
54. # [00:19] * Joins: glazou (glazou@17.244.0.83)
55. # [00:19] <fantasai> Tab: This example is simple one, for border-radius.
56. # [00:20] <fantasai> Tab: If one implementation had a slightly different syntax, you could just change it in the mixin definition
57. # [00:20] <fantasai> Tab: And you only need to write it once
58. # [00:20] <fantasai> Tab: every time you need border-radius
59. # [00:20] <fantasai> glazou talks about HTML5's versioning model
60. # [00:20] <fantasai> Tab: I don't like HTML5's model. It's much nicer in JavaScript
61. # [00:21] <fantasai> s/HTML5/HTML
62. # [00:21] <fantasai> /
63. # [00:21] <fantasai> Tab: JavaScript can afford to be ugly because you can layer a nice api over it
64. # [00:21] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
65. # [00:22] <fantasai> dbaron: I think the big problem is not the model, but the timing of how we've been advancing properties
66. # [00:22] * Joins: alexmog (alexmog@17.244.1.2)
67. # [00:22] <fantasai> ?: It's been a problem only for a few, more than one but only a few
68. # [00:22] <fantasai> s/?/howcome/
69. # [00:23] <fantasai> glazou: Whether it's a problem for a property depends a lot on how popular it is
70. # [00:23] <fantasai> ...
71. # [00:24] <fantasai> Alex: Isn't it a problem that we have an unprefixed 'zoom' property? It looks like a regular standard property but it isn't
72. # [00:24] <fantasai> dbaron: We haven't changed our border-radius prefix because we don't yet match the current spec
73. # [00:24] <fantasai> dbaron: Most of those issues are not even syntactic
74. # [00:25] <fantasai> dbaron: There are a lot of requirements in the current spec that we don't implement
75. # [00:25] <fantasai> dbaron: I had questioned at the time whether the spec needed to require things in that much detail
76. # [00:26] <fantasai> howcome: I think you should drop the prefix anyway. Even if you have some bugs left. THey're just bugs
77. # [00:26] <fantasai> Brad: If we had dropped the prefix for border-image earlier, we'd be stuck with that
78. # [00:27] <fantasai> Brad: We wouldn't be able to make the changes I proposed.
79. # [00:27] <fantasai> Brad: We thought it was stable.
80. # [00:27] <fantasai> dbaron: I've heard comments from people who were unhappy that the prefixed versions didn't match the spec
81. # [00:27] <fantasai> ...
82. # [00:28] <fantasai> Steve: Why isn't macros, by any other name, a good solution to this?
83. # [00:28] <fantasai> glazou asks questions that were answered previously
84. # [00:29] <fantasai> the minute-taker will not repeat the answers
85. # [00:29] <fantasai> plinss: If they have different behavior?
86. # [00:29] <Bert> (One way to do mixins, especially usefule if you work with Ruby: http://dev.w3.org/csswg/css3-tables-algorithms/Overvie w.src.htm
87. # [00:29] <fantasai> Tab: If it's just syntactic, you can work around it. If you can't, then you're screwed anyway
88. # [00:30] <Bert> Wrong paste, I meant http://sass-lang.com/ )
89. # [00:30] <fantasai> Steve: If they don't do what you want, dropping the prefix isn't helpful anyway
90. # [00:30] <fantasai> Plinss: The problem with this is, what if I change something via JavaScript?
91. # [00:30] <fantasai> Anne: Maybe you don't see it in JavaScript
92. # [00:30] <fantasai> ...
93. # [00:30] <fantasai> howcome: This saves people 30 seconds of copy-pasting. It's not really a problem
94. # [00:32] <fantasai> howcome: I think this problem is over-rated
95. # [00:32] <anne> I agree with howcome
96. # [00:32] * fantasai agrees with Tab
97. # [00:33] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
98. # [00:33] <fantasai> Tab: If we want to drop prefixes on something not in CR, we should pull it out into another module
99. # [00:33] * Joins: alexmog (alexmog@17.244.1.2)
100. # [00:33] <fantasai> Bert: We did that with css3-backgrounds, we dropped box-shadow so we could move everything else forward
101. # [00:33] <fantasai> Tab: Yes. That would solve this while giving us all the benefits of CR.
102. # [00:34] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
103. # [00:34] <fantasai> Steve: We can solve this problem by focusing on what's important and pushing that forward
104. # [00:35] <fantasai> glazou: You don't know whether something's going to be succesful when you design it
105. # [00:36] <fantasai> some arguments that it doesn't matter, you'll find out quickly
106. # [00:36] <fantasai> others that you can predict it for some things anyway
107. # [00:36] <fantasai> Steve: Once you find out something is popular, then you progress it faster.
108. # [00:36] * Joins: dbaron (dbaron@63.245.220.11)
109. # [00:38] <fantasai> glazou: If we accept the extra work to extract properties and push it forward, then it's not a problem
110. # [00:39] <fantasai> Chris: Depends on how much of the spec is stable. If it's mostly stable, pull the unstable things out and move the whole thing
111. # [00:39] <fantasai> Chris: If it's mostly unstable, extract the stable parts and push that forward.
112. # [00:41] <fantasai> Anne: Other WG's have pseudo-stable drafts that are implemented and shipped, and only take small changes
113. # [00:41] <fantasai> Anne: It seems to work relatively well
114. # [00:41] <fantasai> Steve: Yes and no
115. # [00:41] <fantasai> -> offline
116. # [00:41] <fantasai> glazou: If we have a high-priority set of properties, let's try to extract them to move faster
117. # [00:43] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
118. # [00:56] <fantasai> Topic: Status-type Stuff
119. # [00:56] <fantasai> Topic: Style-attr spec
120. # [00:56] <fantasai> glazou: Last Call period ended. Need to check comments and write disposition of comments
121. # [00:57] <fantasai> fantasai: I'm waiting for a response from SVGWG, other than that it's pretty much done
122. # [00:57] <fantasai> http://dev.w3.org/csswg/css-style-attr/issues-lc-2009
123. # [00:59] * Joins: dbaron (dbaron@17.244.2.46)
124. # [01:00] <fantasai> dbaron: Should include tests for common problems
125. # [01:00] <fantasai> dbaron: like braces around the declaration block
126. # [01:00] <fantasai> Topic: Media Queries
127. # [01:00] <fantasai> glazou: CR period ended a few months ago
128. # [01:00] <fantasai> glazou: We dont' have a test suite, I think
129. # [01:00] <fantasai> Anne: a lot of tests submitted, but no suite
130. # [01:00] <fantasai> glazou: So, what do we do?
131. # [01:01] <fantasai> Anne: We find someone to go through the tests and make a test suite
132. # [01:01] <fantasai> howcome: We already found him
133. # [01:01] <fantasai> howcome: Can't you do that?
134. # [01:01] <fantasai> anne: I'm not sure I want to
135. # [01:01] <fantasai> howcome: That wasn't my question :)
136. # [01:01] <fantasai> anne: We have a lot of different tests, they're not all in the same format
137. # [01:03] <fantasai> Anne explains some of the types of tests that were submitted
138. # [01:04] <fantasai> discussion of how to test the 'grid' feature
139. # [01:04] * Quits: plinss__ (plinss@17.244.3.217) (Quit: plinss__)
140. # [01:07] <fantasai> glazou: Are you able to handle the media queries test suite, or not?
141. # [01:07] <fantasai> anne: I would rather not. I haven't done any work on it
142. # [01:07] <fantasai> anne: the tests are posted to various mailing lists
143. # [01:08] <fantasai> ACTION: Chris Find tests for media queries and check into test repository
144. # [01:08] * trackbot noticed an ACTION. Trying to create it.
145. # [01:08] <trackbot> Sorry, amibiguous username (more than one match) - Chris
146. # [01:08] <trackbot> Try using a different identifier, such as family name or username (eg. ChrisWilson, clilley)
147. # [01:08] * RRSAgent records action 2
148. # [01:08] <fantasai> Anne: I'm sort of swamped with editing
149. # [01:08] <fantasai> ACTION: clilley Find tests for media queries and check into test repository
150. # [01:08] * trackbot noticed an ACTION. Trying to create it.
151. # [01:08] * RRSAgent records action 3
152. # [01:08] <trackbot> Created ACTION-211 - Find tests for media queries and check into test repository [on Chris Lilley - due 2010-04-05].
153. # [01:08] <fantasai> Topic: Namespaces
154. # [01:09] <fantasai> glazou: We're in CR, it is implemented
155. # [01:09] <fantasai> dbaron: I think we fixed the one parsing bug we had
156. # [01:09] <fantasai> glazou: We need implementation reports
157. # [01:11] <fantasai> dbaron: If the bug is in the 2.1 implementation, can we say that the bug is in the 2.1 spec implementation and for the purposes of Namespaces it's a pass?
158. # [01:14] <dbaron> Implementation report Firefox 3.6.2 Linux: all tests pass
159. # [01:14] <fantasai> dbaron: All tests pass on FF3.7 Linux
160. # [01:14] <dbaron> http://www.w3.org/Style/CSS/Test/CSS3/Namespace/current/
161. # [01:15] <fantasai> ACTION: glazou make namespaces implementation reports
162. # [01:15] * trackbot noticed an ACTION. Trying to create it.
163. # [01:15] * RRSAgent records action 4
164. # [01:15] <trackbot> Created ACTION-212 - Make namespaces implementation reports [on Daniel Glazman - due 2010-04-05].
165. # [01:15] <fantasai> Topic: CSS3 Page
166. # [01:16] <fantasai> fantasai: It needs a lot more work before another Last Call
167. # [01:17] <fantasai> Topic: CSS3 Backgrounds and Borders
168. # [01:18] <fantasai> fantasai: Planning to write 10-15 tests to set up, then will be easier to accept submissions. Probably nothing complete until August F2F at the earliest
169. # [01:18] <fantasai> Topic: CSS3 Color
170. # [01:18] <fantasai> dbaron: Some LC comments are non-trivial. We should go through the comments some time this meeting
171. # [01:19] <fantasai> dbaron: The current editor's draft addresses most, but not all, issues. Haven't sent responses yet.
172. # [01:19] <dbaron> http://wiki.csswg.org/spec/css3-color is the issues list
173. # [01:20] <fantasai> Topic: Background Shorthand Syntax, to slash or not to slash
174. # [01:20] * Bert wonders... "to slash" is that the same as "to nuke" :-)
175. # [01:24] <TabAtkins> fantasai: 4 issues, somewhat related.
176. # [01:24] <TabAtkins> fantasai: All effect the shorthand.
177. # [01:24] <TabAtkins> fantasai: sylvain's issue was background-clip.
178. # [01:25] * Quits: arronei (arronei@131.107.0.94) (Client exited)
179. # [01:25] * Joins: arronei (arronei@131.107.0.83)
180. # [01:26] <TabAtkins> fantasai: Start with background-clip, do we allow content-box?
181. # [01:27] <TabAtkins> fantasai: As well, in the shorthand, I suggest that if *-box appears once, it sets both origin and clip, while if it appears twice, it sets origin *then* clip.
182. # [01:28] <TabAtkins> bradk: I wanted to do bg-size first, so I could bring up that we could use a slash to disambiguate this as well.
183. # [01:29] * Joins: plinss__ (plinss@17.244.3.217)
184. # [01:29] <TabAtkins> bradk: [on board] Right now you've got like "/ <bg-size>".
185. # [01:30] <TabAtkins> bradk: So apply that the same to origin/clip, so you could say, like "border-box / padding-box" or just "border-box" or just "/ padding-box".
186. # [01:32] <TabAtkins> TabAtkins: I want to avoid / whenever possible, though.
187. # [01:33] <TabAtkins> bradk: We're already using /s in various properties, border-radius, font, border-image.
188. # [01:33] <TabAtkins> TabAtkins: In a lot of those, though, you're splitting apart lists of numbers, and it's *impossible* to tell where things start and end without the /. With keywords you don't need to do that.
189. # [01:34] <TabAtkins> anne: Other places with keywords, like overflow, don't need a /.
190. # [01:34] <TabAtkins> anne: And background-repeat.
191. # [01:34] <TabAtkins> bradk: You need *something* to separate bg-position and bg-size.
192. # [01:34] <TabAtkins> anne: Yeah.
193. # [01:35] <TabAtkins> bradk: You get some freedom with how you write things with the /
194. # [01:35] <TabAtkins> anne: Is that freedom actually needed, though?
195. # [01:36] <TabAtkins> TabAtkins: I don't think we need to generalize in order to solve the position/size issue. Other places where we have a /, we definitely need it; other places where we don't, we definitely don't.
196. # [01:36] <TabAtkins> fantasai: I think separating them would make things more difficult.
197. # [01:37] <TabAtkins> fantasai: When you're parsing, you can just shove stuff into data structures directly.
198. # [01:37] <TabAtkins> fantasai: You don't have to remember what has come before.
199. # [01:38] <TabAtkins> fantasai: That's part of why Yves wanted to relax the restriction on ordering, so you just have to look at the previous token to see if it's valid to put in a bg-position, rather than having to remember that you had a size earlier in the rule.
200. # [01:38] <TabAtkins> fantasai: position is always a position. If size is completely absent, it's a position.
201. # [01:38] <TabAtkins> bradk: Don't you have to read ahead to see if there's a size?
202. # [01:39] * Quits: dbaron (dbaron@17.244.2.46) (Ping timeout)
203. # [01:39] <TabAtkins> fantasai: No, as soon as you hit lengths, you know it's a position. And then, later, you might see a slash denoting a size.
204. # [01:40] * glazou notes the readability argument was not a valid one in case of nested at-rules but is one now :-)
205. # [01:40] <TabAtkins> Bert: I think the main issue is just one of readability.
206. # [01:41] * glazou BTW Cupertino Inn served us free drinks (whatever you want) until 7pm yesterday ; probably valid every day :)
207. # [01:41] <TabAtkins> [discussion about human/machine parsability with a / anywhere in the rule versus / immediately before a size]
208. # [01:45] <TabAtkins> TabAtkins: So can we add content-box to bg-clip, and accept the shorthand?
209. # [01:45] * anne yay for free drinks
210. # [01:46] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
211. # [01:46] <TabAtkins> strawpoll: Add content-box to background-clip?
212. # [01:47] <TabAtkins> Abstain? 6
213. # [01:47] <TabAtkins> Objections? 0
214. # [01:47] <TabAtkins> RESOLVED: Add content-box to bg-clip
215. # [01:47] <TabAtkins> RESOLVED: Allow setting bg-origin and clip in shorthand
216. # [01:51] <TabAtkins> fantasai: Disallow "/size position", definitely.
217. # [01:51] * Joins: dsinger__ (mobile@17.244.3.165)
218. # [01:52] <TabAtkins> fantasai: Allow "position url /size" and "/size url position"?
219. # [01:52] <TabAtkins> fantasai: Or restrict it to *only* "position/size"?
220. # [01:53] * dsinger__ is now known as dsinger_
221. # [01:54] <TabAtkins> RESOLVED: Change background shorthand to have "<bg-position> [/ <bg-size>]". (Position is required if you specify size.)
222. # [01:54] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Feb/0238.html
223. # [01:54] <TabAtkins> fantasai: Small one about border-radius.
224. # [01:54] <TabAtkins> fantasai: 1) Define gradient stops in more detail. 2) Dont' define color-transitions at all.
225. # [01:55] <TabAtkins> howcome: So what was the problem before?
226. # [01:55] * Quits: dsinger_ (mobile@17.244.3.165) (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
227. # [01:55] * Joins: dsinger__ (mobile@17.244.3.165)
228. # [01:55] <TabAtkins> sylvaing: Today with different-colored borders, you get a sharp border. If we want a gradient, we need a way that's interop across browsers.
229. # [01:56] <TabAtkins> ChrisL: Currently the spec tells you where on the curve the midpoint is.
230. # [01:56] * Quits: howcome (howcome@17.244.0.146) (Ping timeout)
231. # [01:56] <TabAtkins> ChrisL: I think we should still be able to get that, and I think that's enough to get a gradient.
232. # [01:56] * dsinger__ is now known as dsinger_
233. # [01:58] <TabAtkins> ChrisL: [describes a linear-gradient based one]
234. # [01:58] <TabAtkins> sylvaing: Could we get it back through CR quickly with that?
235. # [01:59] * Quits: dsinger_ (mobile@17.244.3.165) (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
236. # [01:59] <ChrisL> in fact i descriped two gradients, one from the start color to the midpoint color and one from the midpoint color to the end color; both linear wrt *angle*
237. # [02:00] <TabAtkins> sylvaing: I see it as a different issue. I want to control my corners, and then I want to control my borders.
238. # [02:00] <TabAtkins> fantasai: I think making it undefined is fine, and then we have an informative appendix.
239. # [02:01] <TabAtkins> szilles: The experience of leaving things undefined is that someone ends up defining them.
240. # [02:02] * Quits: jer (jer@17.244.2.51) (Quit: jer)
241. # [02:02] <TabAtkins> ChrisL: I understand the argument of doing the simple thing now and the complicated thing now. But what I don't like is some browsers having a sharp transition and you do a smooth transition because you think it looks better.
242. # [02:03] <TabAtkins> dbaron: I haven't seen authors complain about this yet, but authors *do* complain about performance, and sharp vs gradients has performance implications.
243. # [02:04] <TabAtkins> sylvaing: If we later do 45deg corners, you'll need a linear gradient, etc.
244. # [02:04] <TabAtkins> fantasai: I'm fine with leaving it undefined right now, and we'll define it in level 4 and we'll be good.
245. # [02:06] <TabAtkins> szilles: But we won't have that freedom after a little bit.
246. # [02:06] <TabAtkins> dbaron: I think I'm okay with that lack of freedom.
247. # [02:06] * Joins: jer (jer@17.244.2.51)
248. # [02:09] <TabAtkins> fantasai: If our browsers do something right now that authors don't like, we'll change.
249. # [02:10] <fantasai> dbaron: sometimes it's best to let the market decide
250. # [02:12] <TabAtkins> sylvaing: I'm fine with specifying sharp transitions, and I'm fine with undefined.
251. # [02:12] <fantasai> "It is not defined what these transitions look like."
252. # [02:12] * Quits: jer (jer@17.244.2.51) (Quit: jer)
253. # [02:13] <fantasai> Tab: I'm fine with explicitly undefined, being defined later possibly constrained by market forces
254. # [02:13] <fantasai> Chris: I would prefer it to be dfined, but I can live with the other options
255. # [02:13] <TabAtkins> arronei: From a testing perspective, I prefer defined.
256. # [02:15] <TabAtkins> dsinger: If someone *requires* a particular effect, they can use a border-image, right? I'm okay with leaving it undefined and waiting to see what people start hacking around it with.
257. # [02:16] <TabAtkins> dbaron: We can define the shape of the border, we can define the limits of the transition, we just won't define what it looks like other than that.
258. # [02:16] <fantasai> RESOLVED: proposal 3 accepted
259. # [02:17] <TabAtkins> szilles: So all existing hard-edged impls match that proposal?
260. # [02:17] <TabAtkins> glazou: yes.
261. # [02:17] <TabAtkins> glazou: howcome, you have the floor for box-shadow
262. # [02:17] <TabAtkins> howcome: box-shadow was removed to gain speed for the spec.
263. # [02:17] <TabAtkins> howcome: We now have 4 interoperable impls of box-shadow, so I think we should put it back in.
264. # [02:18] <TabAtkins> howcome: Or else put it in it's own spec.
265. # [02:18] <TabAtkins> glazou: I have some tests, and it looks interoperable.
266. # [02:19] <TabAtkins> howcome: [looking at MS people] I suspect they have something up their sleeve.
267. # [02:19] <TabAtkins> sylvaing: We'd like to see it back in.
268. # [02:20] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
269. # [02:21] <TabAtkins> howcome: So we have interop, why was it removed?
270. # [02:21] * Joins: dbaron (dbaron@17.244.2.46)
271. # [02:22] <TabAtkins> TabAtkins: There were significant complications being suggested, to the point where it *was* going to slow the draft. A very simple box-shadow, what we have interop on, would have been ok.
272. # [02:23] <TabAtkins> howcome: My position is that we add it back in. Simple list of lengths, a color, an inset/outset keyword. Purely rectangular (module border-radius).
273. # [02:24] <TabAtkins> RESOLVED: Put the simple version of box-shadow back into B&B.
274. # [02:24] <TabAtkins> Topic: GCPM - env() function
275. # [02:24] <plinss__> http://dev.w3.org/csswg/css3-gcpm/
276. # [02:24] * Joins: howcome (howcome@17.244.0.146)
277. # [02:24] * Joins: miketaylr (miketaylr@24.42.95.234)
278. # [02:24] <plinss__> http://dev.w3.org/csswg/css3-gcpm/#string-set
279. # [02:25] <TabAtkins> howcome: If you print in most browsers, the browser will put the time of printing in the margin box.
280. # [02:25] <TabAtkins> howcome: The idea is to make it possible to get that info in CSS.
281. # [02:25] <ChrisL> env(location.lattitude)
282. # [02:26] <dbaron> Is this going to gradually turn into strftime?
283. # [02:26] <TabAtkins> dbaron, yes.
284. # [02:27] * Quits: dethbakin (dethbakin@17.246.18.154) (Quit: dethbakin)
285. # [02:27] <dbaron> 2010年04月02日 vs. 2010-04-02 vs. 2/4/10 vs. 4/2/10 vs. 2/4/2010 vs. 4/2/2010
286. # [02:27] <TabAtkins> glazou: A long while ago, around CSS2, we had a proposal for a date() function, Michelle Wolfe (sp?) gave a long, excellent argument for why date is no good.
287. # [02:27] <glazou> s/Michelle/Mischa
288. # [02:28] <dbaron> s/Michelle Wolfe/Misha Wolf/
289. # [02:28] <dbaron> s/Mischa Wolfe/Misha Wolf/
290. # [02:29] <TabAtkins> szilles: How does the system know what to output the date as?
291. # [02:29] <TabAtkins> glazou: From the system locale.
292. # [02:30] <TabAtkins> szilles: That assumes the locale it is printed in is the same as the locale it is read for.
293. # [02:30] <TabAtkins> glazou: That's the same problem that you *already have* with dates on printouts, you're just styling them now.
294. # [02:31] <TabAtkins> [discussion of how Word does stuff/locale bindings]
295. # [02:32] <TabAtkins> howcome: There is a way to just ask the system for the date, and env(date) would just give that.
296. # [02:32] <TabAtkins> szilles: What's the use-case for this?
297. # [02:33] <TabAtkins> howcome: Use-case is, when a browser prints a page today, they put the date on the printout. This would give you control over that.
298. # [02:33] <TabAtkins> szilles: I'm printing a document that's written in Armenian, and I'm going to distribute it to my Armenian friends.
299. # [02:34] <TabAtkins> howcome: By adding this feature, we allow ourselves to turn it off as well.
300. # [02:36] <TabAtkins> szilles: I could potentially turn it off with just a little checkbox in some preferences.
301. # [02:37] <TabAtkins> TabAtkins: No browser lets you do that right now. We can solve it through CSS.
302. # [02:38] * css_projector thinks this is a tarpit
303. # [02:38] <TabAtkins> Bert: Some javascript to get at things from your environment (such as if you are counting in the jewish date) that you may not want.
304. # [02:39] <TabAtkins> glazou: You already have (new Date()).toLocaleString().
305. # [02:39] * ChrisL css_projector ++
306. # [02:39] <TabAtkins> szilles: My issue isn't with whether you want url or date. My issue is more the discussion from Mischa, where the date is a very dangerous thing.
307. # [02:40] <TabAtkins> szilles: I don't think there's a such thing as the "date".
308. # [02:41] <TabAtkins> TabAtkins: You're trying to add things to what we just want to simply cssify.
309. # [02:41] <anne> javascript:(new Date).toLocaleString()
310. # [02:41] <anne> Monday March 29, 17:38:45 GMT-0700 2010
311. # [02:42] <TabAtkins> smfr: Is the intent to limit it to Paged Media?
312. # [02:42] <TabAtkins> howcome: No, it can go in content property, so it can go anywhere potentially.
313. # [02:42] * Quits: anne (annevk@17.244.3.72) (Client exited)
314. # [02:43] * Joins: anne (annevk@17.244.3.72)
315. # [02:43] <TabAtkins> smfr: When is the date set? Is it live? Does it update when the page is refreshed? What about if layout changes something?
316. # [02:43] * Quits: anne (annevk@17.244.3.72) (Client exited)
317. # [02:43] <TabAtkins> glazou: More detail is needed there.
318. # [02:43] * Joins: anne (annevk@17.244.3.72)
319. # [02:43] <TabAtkins> glazou: Sometimes when printing, the *username* is displayed on the printout. We shouldn't give access to that.
320. # [02:44] * Quits: sylvaing (sylvaing@17.244.0.225) (Ping timeout)
321. # [02:44] <TabAtkins> howcome: So it seems like this is potentially a useful thing, but there are security and i18n concerns.
322. # [02:44] <TabAtkins> bradk: Date, or date and time?
323. # [02:44] <TabAtkins> howcome: We can do env(date) and env(time).
324. # [02:45] <TabAtkins> plinss: Some printouts have the document title.
325. # [02:45] <TabAtkins> howcome: You can already pull that from <title> using string-set.
326. # [02:45] <smfr> http://dev.w3.org/csswg/css3-gcpm/#turning-elements-into-footnotes
327. # [02:45] <TabAtkins> howcome: Small issue with footnotes. If you're in the draft, look at example XXIV
328. # [02:46] <TabAtkins> howcome: display footnotes stacked vertically, or flowed inline.
329. # [02:47] <TabAtkins> howcome: My first idea is to use display on the footnote element that determines what it does here.
330. # [02:48] <TabAtkins> howcome: But I think this is sorta inconvenient, as when you're floating an inline element you'd have to explicitly set display:block.
331. # [02:48] <TabAtkins> arronei: What about float:footnote and float:inline-footnote? Then you don't have to mess with display.
332. # [02:48] <TabAtkins> TabAtkins: I like that idea.
333. # [02:49] <TabAtkins> bradk: And could we then do display: list-item on the footnote to auto-generate the marker.
334. # [02:50] <TabAtkins> glazou: You cannot use list-item, because it precludes an inline footnote.
335. # [02:51] <TabAtkins> howcome: Suggestion: Put display:inline on the @footnote rule, to switch the display type of the footnotes. It's a bit of a hack, but display is otherwise unused in @footnote.
336. # [02:52] * Joins: sylvaing (sylvaing@17.244.0.225)
337. # [02:52] * sylvaing ::nth-footnote(2n+1) { content:env(...
338. # [02:53] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Carrier dropped, no sig$%^&&&*.....)
339. # [02:54] <TabAtkins> howcome: Input is great, we'll discuss more on the list.
340. # [02:54] <TabAtkins> howcome: I'd also like a new editor's draft.
341. # [02:54] * Quits: sylvaing (sylvaing@17.244.0.225) (Quit: sylvaing)
342. # [02:54] * Quits: TabAtkins (chatzilla@17.244.2.48) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.13/2009073109])
343. # [02:54] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
344. # [02:55] * Quits: bradk (bradk@17.244.0.81) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
345. # [02:56] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
346. # [02:56] * Quits: Arron (arronei@17.244.2.216) (Ping timeout)
347. # [02:57] * Quits: anne (annevk@17.244.3.72) (Ping timeout)
348. # [02:58] * Quits: dbaron (dbaron@17.244.2.46) (Quit: 8403864 bytes have been tenured, next gc will be global.)
349. # [02:59] * Quits: css_projector (css_projec@17.201.14.208) (Quit: css_projector)
350. # [03:00] * Quits: plinss__ (plinss@17.244.3.217) (Quit: plinss__)
351. # [03:04] * Quits: smfr (smfr@17.244.1.194) (Quit: smfr)
352. # [03:07] * Quits: howcome (howcome@17.244.0.146) (Ping timeout)
353. # [03:11] * Joins: shepazu_ (schepers@128.30.52.169)
354. # [03:15] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
355. # [03:30] * Joins: Curt` (DorkeyDear@76.241.90.62)
356. # [03:44] * Joins: TabAtkins (chatzilla@76.253.3.102)
357. # [04:00] * Joins: karl (karlcow@128.30.54.58)
358. # [04:35] * Quits: dino (dino@17.202.116.62) (Quit: dino)
359. # [04:40] * Joins: plinss__ (plinss@72.254.95.180)
360. # [04:46] * shepazu_ is now known as shepazu
361. # [05:20] * Quits: Curt` (DorkeyDear@76.241.90.62) (Quit: Leaving)
362. # [05:38] * Quits: plinss__ (plinss@72.254.95.180) (Quit: plinss__)
363. # [05:42] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
364. # [05:48] * Quits: paul_irish (paul_irish@71.192.163.128) (Ping timeout)
365. # [05:55] * Joins: smfr (smfr@68.183.233.103)
366. # [06:13] * Joins: paul_irish (paul_irish@65.96.162.9)
367. # [06:16] * Joins: TabAtkins (chatzilla@76.253.3.102)
368. # [06:19] * Quits: paul_irish (paul_irish@65.96.162.9) (Client exited)
369. # [06:55] * Joins: paul_irish (paul_irish@65.96.162.9)
370. # [06:58] * Quits: paul_irish (paul_irish@65.96.162.9) (Client exited)
371. # [06:58] * Joins: paul_irish (paul_irish@65.96.162.9)
372. # [06:59] * Quits: paul_irish (paul_irish@65.96.162.9) (Client exited)
373. # [07:08] * Quits: smfr (smfr@68.183.233.103) (Quit: smfr)
374. # [07:16] * Joins: mib_a17avm (4ad80c06@64.62.228.82)
375. # [07:18] * Parts: mib_a17avm (4ad80c06@64.62.228.82)
376. # [07:20] * Quits: miketaylr (miketaylr@24.42.95.234) (Client exited)
377. # [07:22] * Joins: findow (4ad80c06@64.62.228.82)
378. # [07:22] <findow> Anyone here?
379. # [07:25] * Quits: findow (4ad80c06@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
380. # [07:26] * Joins: Arron (arronei@173.200.179.65)
381. # [07:33] * Joins: mib_mjip2q (4ad80c06@64.62.228.82)
382. # [07:33] * Quits: mib_mjip2q (4ad80c06@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
383. # [07:47] * Quits: Arron (arronei@173.200.179.65) (Ping timeout)
384. # [07:49] * Joins: anne (annevk@76.253.3.102)
385. # [07:59] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
386. # [08:06] * Quits: anne (annevk@76.253.3.102) (Ping timeout)
387. # [08:25] * Joins: TabAtkins (chatzilla@76.253.3.102)
388. # [09:06] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
389. # [09:18] * Quits: plinss_ (plinss@192.6.114.30) (Ping timeout)
390. # [10:19] * Joins: lstorset (lstorset@213.236.208.22)
391. # [10:19] * Parts: lstorset (lstorset@213.236.208.22)
392. # [12:23] * Joins: lstorset (lstorset@213.236.208.22)
393. # [12:26] * Parts: lstorset (lstorset@213.236.208.22)
394. # [12:27] * Quits: fantasai (fantasai@66.55.71.177) (Ping timeout)
395. # [12:37] * Joins: fantasai (fantasai@66.55.71.177)
396. # [12:42] * Quits: fantasai (fantasai@66.55.71.177) (Ping timeout)
397. # [12:50] * Joins: fantasai (fantasai@66.55.71.177)
398. # [15:12] * Joins: paul_irish (paul_irish@65.96.162.9)
399. # [15:13] * Joins: miketaylr (miketaylr@38.117.156.163)
400. # [15:26] * Joins: anne (annevk@76.253.3.102)
401. # [15:47] * Quits: paul_irish (paul_irish@65.96.162.9) (Client exited)
402. # [15:47] * Joins: paul_irish (paul_irish@65.96.162.9)
403. # [16:08] * Quits: paul_irish (paul_irish@65.96.162.9) (Client exited)
404. # [16:15] * Joins: TabAtkins (chatzilla@76.253.3.102)
405. # [16:21] * Joins: paul_irish (paul_irish@64.61.60.146)
406. # [16:31] * Quits: paul_irish (paul_irish@64.61.60.146) (Client exited)
407. # [16:32] * Joins: myakura (myakura@122.17.119.104)
408. # [16:32] * Quits: myakura (myakura@122.17.119.104) (Quit: Leaving...)
409. # [17:13] * Joins: Arron (arronei@173.200.179.65)
410. # [17:30] * Joins: alexmog (alexmog@173.200.179.65)
411. # [17:34] * Quits: anne (annevk@76.253.3.102) (Ping timeout)
412. # [17:35] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
413. # [17:47] * Joins: CSS-projector (apple@17.201.14.208)
414. # [17:48] * CSS-projector Good Morning!
415. # [17:54] * Quits: alexmog (alexmog@173.200.179.65) (Ping timeout)
416. # [17:54] * Quits: Arron (arronei@173.200.179.65) (Ping timeout)
417. # [17:56] * Joins: TabAtkins (chatzilla@17.244.2.48)
418. # [17:57] * Joins: anne (annevk@17.244.3.72)
419. # [18:03] * Joins: Arron (arronei@17.244.2.216)
420. # [18:04] * Joins: alexmog (alexmog@17.244.1.2)
421. # [18:04] * Joins: sylvaing (sylvaing@17.244.0.225)
422. # [18:06] * Joins: bradk (bradk@17.244.0.81)
423. # [18:07] * Joins: smfr (smfr@17.244.1.194)
424. # [18:08] * Joins: plinss_ (plinss@17.244.3.217)
425. # [18:08] <smfr> http://wiki.csswg.org/planning/cupertino-2010
426. # [18:08] * Joins: dbaron (dbaron@63.245.220.11)
427. # [18:13] * CSS-projector congrats to John!
428. # [18:14] * Joins: glazou (glazou@17.244.0.83)
429. # [18:14] <glazou> RRSAgent, make logs public
430. # [18:14] <RRSAgent> I have made the request, glazou
431. # [18:15] <TabAtkins> ScribeNick: TabAtkins
432. # [18:15] * dbaron wonders what it is that smfr said to reload
433. # [18:15] <TabAtkins> Topic: Transitions of non-animatable properties
434. # [18:15] <glazou> RRSAgent, http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html
435. # [18:15] <RRSAgent> I'm logging. I don't understand 'http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html', glazou. Try /msg RRSAgent help
436. # [18:15] * Joins: dethbakin (dethbakin@17.244.0.186)
437. # [18:15] * Joins: szilles (chatzilla@17.244.3.121)
438. # [18:16] <smfr> http://wiki.csswg.org/planning/cupertino-2010
439. # [18:16] <TabAtkins> dbaron: Transitions spec currently has a special case for visibility.
440. # [18:17] <TabAtkins> dbaron: We may want to keep it despite this, but the idea for the special case is the if visibility has a transition from 'visible' to 'hidden', it's considered to be a property that can transition, where all intermediate states are transitionable.
441. # [18:17] <glazou> rrsagent, this meeting spans midnight
442. # [18:17] <RRSAgent> ok, glazou; I will not start a new log at midnight
443. # [18:17] <TabAtkins> dbaron: So if you're transition from visible to hidden, the transition happens when a timing funciton ends.
444. # [18:17] <TabAtkins> dbaron: This makes sense if you're, say, shrinking something and then want it to disappear entirely.
445. # [18:18] <TabAtkins> dbaron: Somebody wanted this to apply in other cases; in particular, they were trying to convert the controls Gecko uses for HTML5 video, which has a number of animations.
446. # [18:18] <TabAtkins> dbaron: He was trying to do them using Transitions, but one thing that happens is a display change. He wants to be able to transition to display:none after an opacity transition happens.
447. # [18:19] <TabAtkins> dbaron: He ended up using the transitionend event, but he'd like to do this just with the transition support.
448. # [18:19] <TabAtkins> dbaron: So what we think we might do is that, for non-animatable properties, we don't have transition-duration support, but *do* have transition-delay support.
449. # [18:20] <TabAtkins> smfr: So you'd take transition-delay into account, and just do an instantaneous transition after that.
450. # [18:21] <TabAtkins> dbaron: If we did this, we might still want to keep this special rule for visibility, because it's a little bit harder to do things this way (you have to do delay for this one property rather than a duration).
451. # [18:21] <TabAtkins> dbaron: Now with visibility, we know that people want visible in the 'middle', but for other properties we don't know what people want in the middle.
452. # [18:21] <TabAtkins> dean: The next topic is discrete timing functions, which would also solve this and give you control over when the non-animatable property transitions.
453. # [18:21] <TabAtkins> dbaron: Yeah.
454. # [18:22] <TabAtkins> dbaron: Are you saying you want to do it the delay way, or the stepwise way, or both...?
455. # [18:22] <TabAtkins> dean: Your way.
456. # [18:22] <TabAtkins> smfr: But if you have stepwise timing functions, you don't necessarily need a delay trick.
457. # [18:23] <smfr> step-wise timing function proposal: http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html
458. # [18:23] <TabAtkins> dean: With a stepwise timing function, if you say something like "I only want a change at the end of the transition", you can control when, say, a display:none transitions.
459. # [18:23] <TabAtkins> dean: Basically I think we can make this decision *without* having to worry about stepwise functions first.
460. # [18:25] <TabAtkins> dsinger: Right. We just need to decide if we fix the transition to happen at the beginning or the end.
461. # [18:26] <TabAtkins> plinss: What about a transition from block to inline? There's no easy answer for start or end.
462. # [18:26] <TabAtkins> smfr: Right, stepwise timing functions have a start and end transition function, so you can decide which one to use.
463. # [18:29] <TabAtkins> dsinger: So if you're not using a stepwise timing function, 0 is start and 1 end, and what do we do in the middle?
464. # [18:29] <TabAtkins> dbaron: I think the rule that's most compatible is to have all non-0 round to 1.
465. # [18:30] <TabAtkins> dbaron: Now most of the time people will want to be able to reverse their transition, so that's a little hard. They'll have to make two different declarations.
466. # [18:30] <TabAtkins> smfr: We talked about the issue of not getting symmetry by default, and there's no easy solution I think.
467. # [18:31] <TabAtkins> dbaron: One thing that just occurred to me is that we could add a property that says "reverse all the timing functions".
468. # [18:31] <TabAtkins> dbaron: So when people transition to a hover state, they can put this property on the hover and make it work.
469. # [18:32] <TabAtkins> smfr: That gets into a weird bit of statefulness.
470. # [18:32] <TabAtkins> TabAtkins: Like what if you go to :hover and then click and activate an :active transition.
471. # [18:32] <glazou> Present: Dino, smfr, annevk, szilles, sylvaing, alexm, dethbakin, Bert, arronei, fantasai, dbaron, bradk, TabAtkins, glazou, plinss, howcome, dsinger
472. # [18:32] <TabAtkins> smfr: How are youd efining the states?
473. # [18:32] <TabAtkins> dbaron: Well, any change. :hover, :active, a class...
474. # [18:33] <TabAtkins> smfr: Tracking states kind of scares me.
475. # [18:33] <TabAtkins> dbaron: It requires the author to track states, not the implementation.
476. # [18:35] <TabAtkins> smfr: All the transitions are reversible, right?
477. # [18:35] <TabAtkins> TabAtkins: Yeah, but to do it right you have to set up, say, a :hover and then a :not(:hover) rule.
478. # [18:36] * Joins: dino (dino@17.244.0.152)
479. # [18:36] <TabAtkins> smfr: So I think we have two non-exclusive proposals.
480. # [18:37] <TabAtkins> smfr: One is to just let delay apply to all properties. The other is to add stepwise timing functions.
481. # [18:38] <TabAtkins> TabAtkins: The stepwise includes making all properties respond to delay, so I'm fine with just going all the way up and adding stepwise timing functions.
482. # [18:40] <TabAtkins> TabAtkins: Is anyone opposed to adding the stepwise timing functions?
483. # [18:40] <TabAtkins> [silenc]
484. # [18:41] <TabAtkins> anne: One question. The use-case we were looking at this morning was transitioning a display:none as well other properties. It can be solved with stepwise timings, but could we also do a transition-start event to activate it?
485. # [18:42] <TabAtkins> anne: Another advantage of making them all animatable is that if we add the ability to interpolate one of the non-animatable ones later, we can just do it.
486. # [18:42] <smfr> http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html
487. # [18:42] <TabAtkins> RESOLVED: Make all properties animatable. (non-0 values round to 1)
488. # [18:45] <TabAtkins> smfr: [explains full stepwise timing-function proposal]
489. # [18:46] <TabAtkins> smfr: You may want to control where an *animatable* property precisely step, so you can have it step, say, halfway through, or control how many steps take place.
490. # [18:46] <TabAtkins> smfr: A good example of this is the progress spinner on Mac OSX. It doesn't smoothly rotate; it does 12 discrete steps, and we can't do that right now with Transitions.
491. # [18:48] <TabAtkins> dean: We'd suggested a few things, like letting someone specify the timing function curve as an SVG Path, but I think this proposal hits the majority of cases very simply.
492. # [18:49] <TabAtkins> howcome: I like this stepwise function, but I don't know if I accept the value of full control of a bezier curve. I think a few keywords would just do it.
493. # [18:50] <TabAtkins> dean: [shows some example of where animation programs allow complex control of a curve]
494. # [18:50] <TabAtkins> dean: Writing a bezier function by hand is hard, but it's easy to understand when you see it.
495. # [18:51] <TabAtkins> howcome: Can we just say that if you want more control, just use SVG? Keywords are the 90% function, right?
496. # [18:51] <TabAtkins> dean: Well, we *also* have the 90% solution; we keep the keywords. But we also then add the bezier function.
497. # [18:52] <TabAtkins> glazou: I think this is an excellent first example of something in CSS that can't be really hand-authored.
498. # [18:52] <TabAtkins> howcome: I get worried when we say we don't care about complexity.
499. # [18:53] <TabAtkins> dbaron: 99% of the implementation complexity is just implementing 'ease'. Doing any other bezier curve is just plugging in two more numbers.
500. # [18:54] <dbaron> s/two more/four more/
501. # [18:54] <TabAtkins> TabAtkins: This doesn't produce any long functions. A bezier is just four numbers.
502. # [18:55] <TabAtkins> szilles: Can't we just have a list of xy pairs?
503. # [18:55] <TabAtkins> smfr: That allows too much possibility of getting things wrong, accidentally defining invalid steps.
504. # [18:56] * Joins: howcome (howcome@17.244.0.146)
505. # [18:56] <TabAtkins> szilles: Sure, but you can do that with just the plain number in step-start().
506. # [18:56] <TabAtkins> TabAtkins: Do you think we *need* that degree of control over the transition steps?
507. # [18:57] * Bert imagines 't-property: top; t-function: sin(t); t-duration: infinite'...
508. # [18:57] <TabAtkins> dean: What I like about the simple form we have is that you can leave off the number entirely and it's very intuitive what happens.
509. # [18:58] <TabAtkins> dean: [gives an example of using a step-start function to animate a second hand on a clock]
510. # [19:01] <TabAtkins> [some confusion about difference between step-start and step-end]
511. # [19:02] <TabAtkins> glazou: I would like it better with something like "steps(60) start" or "steps(60,start)".
512. # [19:03] <TabAtkins> dean: Yeah, that's fine, but we also want an author to be able to do the simple case without having to write much, like just "steps" or "steps(start)".
513. # [19:03] * Quits: alexmog (alexmog@17.244.1.2) (Connection reset by peer)
514. # [19:03] <Bert> (I don't believe you can animate a rotation: rotate(0) and rotate(360) look exactly the same, moving the box from one to the other is a no-op, isn't it? And 60 steps of no-op is still a no-op.)
515. # [19:03] * Joins: alexmog (alexmog@17.244.1.2)
516. # [19:04] <TabAtkins> glazou: No, they end up looking the same, but it's still a different thing.
517. # [19:05] <TabAtkins> Bert: Where is it specified that you transition the value of the rotate function?
518. # [19:05] <smfr> http://www.w3.org/TR/2009/WD-css3-2d-transforms-20091201/#matrix-decomposition
519. # [19:05] <TabAtkins> dean: In the Transitions spec, there's a big section defining how to animate Transforms.
520. # [19:05] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
521. # [19:06] <TabAtkins> Bert: If you had a rotate and a translate both?
522. # [19:07] <TabAtkins> dean: If the from state and the to state have the same transform functions in order, you pick them up in order and transition each one independently.
523. # [19:07] <glazou> glazou: no, 360deg and 0deg are not the same ; we all wrote our first draw-a-circle-on-screen program iterating from 0deg to 360deg
524. # [19:07] <TabAtkins> dean: If they don't match, you do the matrix decomposition and animate that, which is defined in Transitions spec.
525. # [19:08] <TabAtkins> Bert: Still a bit confused about transitions when the start and end state look the same.
526. # [19:09] <TabAtkins> dean: I think you're confused because you haven't read the transition spec yet.
527. # [19:09] <TabAtkins> Bert: Does this apply to color as well? If you transition from an rgba color to an hsl color?
528. # [19:09] <TabAtkins> smfr: Right now we define it as transitioning through rgb space.
529. # [19:09] <TabAtkins> dean: The problem is defining exactly how to transition the hue.
530. # [19:10] <TabAtkins> dean: But we may have control over this later.
531. # [19:10] * glazou suggests to rename the 2D transforms module "Matrix Reloaded" and 3d "Matrix Revolutions" for the 1st of April...
532. # [19:10] <TabAtkins> dean: SMIL and SVG don't give you these controls either.
533. # [19:11] <TabAtkins> howcome: Some implementor told me there was some ambiguity.
534. # [19:11] <TabAtkins> dean: I think the spec might just say it in a single sentence or something.
535. # [19:11] <TabAtkins> dean: So, back to steps.
536. # [19:12] <TabAtkins> smfr: I'm happy with what daniel proposed ("steps() function")
537. # [19:13] <TabAtkins> dean: Maybe it should be step() instead, and we decide whether it goes at the start or end?
538. # [19:14] <TabAtkins> glazou: Just do step-start and step-end, and then steps().
539. # [19:14] <TabAtkins> dean: Okay.
540. # [19:14] <TabAtkins> szilles: I think the usage of the words is inconsistent. [step "start" and "end" referring to different things]
541. # [19:15] <anne> step() and step-delayed()
542. # [19:15] <TabAtkins> howcome: Perhaps we can just write it down now, and come up with a better word later?
543. # [19:15] <bradk> align-steps(start|end)?
544. # [19:17] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
545. # [19:17] <Bert> Why 2 functions, why not just step(n) where n >= 1, 1 by default?
546. # [19:17] <TabAtkins> RESOLVED: Accept stepwise timing functions, with modifications suggested in minutes (step-start and step-end keywords, plus steps(number,[start|end]) function)
547. # [19:22] <Bert> (Actually, step(0) as the default is better, then n is the number of intermediate steps.)
548. # [19:23] <Bert> (or stepS().)
549. # [19:30] <Bert> (If you want the possibility of unequal steps, you could do steps(0%,0%,20%,50%,80%,85%,90%). But that may be unnecessary.)
550. # [19:34] * Joins: szilles (chatzilla@17.244.3.121)
551. # [19:36] <fantasai> +Tantek
552. # [19:37] <TabAtkins> Topic: Progressing Transitions (+ Animations?
553. # [19:38] <howcome> http://people.opera.com/howcome/2010/talks/03-csswg-cupertino-ta.html
554. # [19:38] <TabAtkins> howcome: Maybe I'm stupid...
555. # [19:38] <TabAtkins> howcome: In my mind, when I come to this [points to exmaple on screen] I see transitions and animations being the same.
556. # [19:39] <TabAtkins> howcome: I think animations are *great* for CSS, but I think we need to have the model clear. I don't think we've ever quite discussed if this is the right model.
557. # [19:39] <TabAtkins> howcome: We should have *one* set of properties, *-duration, *-timing-function, *-delay.
558. # [19:39] <TabAtkins> howcome: I wanted to do an animation and a transition, and I wanted them to do the same thing. They're basically the same code, except in one I specify a transition and in one I name an animation.
559. # [19:40] <TabAtkins> howcome: There are some minor differences.
560. # [19:40] <TabAtkins> glazou: They're not minor. In transitions the start is defined from context, not explicitly in the animation.
561. # [19:41] <TabAtkins> howcome: [shows Simon's example of combining transitions and animations]
562. # [19:42] <TabAtkins> howcome: In my head, it's arbitrary whether you write transitions or animations.
563. # [19:42] <TabAtkins> dean: I will raise you a head and say "Well, margin and padding are the same thing, so let's make them the same."
564. # [19:42] * Joins: ChrisL (ChrisL@128.30.52.169)
565. # [19:43] <TabAtkins> howcome: Good argument, but I could also say something about webfonts being completely different. But we found a model where they work together with local fonts.
566. # [19:43] <TabAtkins> dean: I think the major difference between transitions and animations is that transition is an effect you have happen whenever styles change, while animations are something you write specifically to happen when you change something.
567. # [19:43] <TabAtkins> howcome: I don't grok that as being so different that you need separate properties for it.
568. # [19:44] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Carrier dropped, no sig$%^&&&*.....)
569. # [19:44] * glazou goes to Cupertino Inn to pick Chris, plinss chairing in the meantime
570. # [19:44] <TabAtkins> smfr: If you open that example in a legacy impl, the transition will make it still move, just instantaneous. The animation one, though, won't do anything.
571. # [19:45] <TabAtkins> smfr: I think it would be useful to add an iteration-count to the animation and see how it compares with transitions.
572. # [19:45] <TabAtkins> dean: dbaron raised the point on the list that you run into a cascade clash. In most cases you want to control transitions as a separate thing, separate from animations.
573. # [19:45] <TabAtkins> dean: [dbaron's issue of additive cascade]
574. # [19:47] <TabAtkins> dean: frex, for a transition you mkight want everything in a document to transition. You can say "* { transition-duration: 1s; }" and everything does it, no further difficulty.
575. # [19:47] <TabAtkins> dbaron: I wrote a strawman syntax proposal on the list that I didn't particular like.
576. # [19:47] <TabAtkins> dbaron: I think I'm in the middle of you guys. I think the cascade thing is something we need to solve a general. We need a way to do additive cascading.
577. # [19:48] <TabAtkins> dbaron: Combining them together makes it a little bit worse in this case, but it's already a problem.
578. # [19:48] <TabAtkins> dbaron: My strawman idea for combining them is - all the transition properties have an animation sibling, except transition-property and animation-name.
579. # [19:49] <TabAtkins> dbaron: Drop the individual properties, have a combined one that takes a function for either a transition property, or an animation name.
580. # [19:49] <TabAtkins> dean: That doesn't solve anything, it just maintains the current separation with a functional syntax.
581. # [19:50] <TabAtkins> TabAtkins: It does partially address howcome's issue, in that it would eliminate 3 nearly identical properties.
582. # [19:50] <TabAtkins> smfr: Is that a problem, though?
583. # [19:50] <TabAtkins> howcome: I think it is.
584. # [19:50] <TabAtkins> smfr: I think there's a fundamental difference there.
585. # [19:50] <TabAtkins> smfr: Transitions kick off when CSS properties change for any reason.
586. # [19:51] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
587. # [19:51] * Joins: alexmog (alexmog@17.244.1.2)
588. # [19:55] <TabAtkins> TabAtkins: [puts up an example of how transitions work]
589. # [19:56] <TabAtkins> plinss: I agree that there are enough similarities that it's *possible* to define animations as a type of transition, or vice versa, but I'm not sure it's worthwhile.
590. # [19:56] <TabAtkins> howcome: I think that's the key question. I want to raise awareness in the room about that possibility.
591. # [19:57] <TabAtkins> szilles: One thing that struck me is that Transitions are parametrized with the old value and new value. In the Animation, you've stuck in a specific value, but the transition has a "variable" of whatever the start and end values.
592. # [19:58] <TabAtkins> smfr: I also think you're missing is that Animations can have multiple properties.
593. # [19:59] <TabAtkins> plinss: Right, so if you key it to Transitions, you could have an animation started by a transition that changes other properties, and then you're into circularity issues.
594. # [20:00] * sylvaing likes the fact that transitions get free fallback for browsers that do not know about transitions; and, vice-versa, that authors can add transitions to their existing stylesheets at low cost
595. # [20:00] <TabAtkins> [conversation shifts to hover/non-hover reversing]
596. # [20:05] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2010Mar/0266.html
597. # [20:06] <smfr> http://smfr.org/misc/tab.html
598. # [20:07] * Joins: dbaron (dbaron@17.244.2.46)
599. # [20:09] <TabAtkins> howcome: We agree that we want this sort of thing possible in CSS? [referring to example]
600. # [20:10] <TabAtkins> everyone: yes
601. # [20:10] <TabAtkins> TabAtkins: But I have a js hack to make that work properly. Without it, the reverse transition happens on page load.
602. # [20:10] <TabAtkins> bradk: :unhover!
603. # [20:10] * Joins: tantek (tantek@173.147.183.213)
604. # [20:10] <TabAtkins> tantek: :was(:hover)!
605. # [20:10] <glazou> in fact that's not what we need
606. # [20:10] * tantek proposes :was() functional selector similar to existing :not()
607. # [20:11] <glazou> we need :will-be(:hover) :-)
608. # [20:11] <TabAtkins> :wants-to-be(:unicorn)
609. # [20:11] <tantek> is true on an element if it the selector inside the parens was ever true on the element since document load.
610. # [20:11] * dbaron RRSAgent, pointer?
611. # [20:11] * RRSAgent See http://www.w3.org/2010/03/29-CSS-irc#T18-09-25
612. # [20:11] * glazou wants a 1st of april Selectors spec with :unicorn and :chinchilla
613. # [20:12] <TabAtkins> szilles: What seems implicit here is that, to combine them, you need an explicit way to refer to the implicit start and end values.
614. # [20:12] * TabAtkins has totally been a bad minuter the last 10 minutes or so.
615. # [20:13] <TabAtkins> szilles: Some things seem simpler than others. Trigger an animation on a transition seems like a relatively simple thing to do.
616. # [20:14] <TabAtkins> dean: It doesn't help our case, but internally we call them 'implicit' and 'explicit' animations. We used a different name now because they really are quite different things.
617. # [20:14] <TabAtkins> dean: [example of how the dock works with both transitions and animations, with the zoom and the bouncing]
618. # [20:14] * Joins: ChrisL (ChrisL@128.30.52.169)
619. # [20:16] <TabAtkins> howcome: You could put them together, just have property names mean a transition and a keyframe name mean an animation.
620. # [20:16] * glazou thinks bad minute takers should be lashed :-)
621. # [20:16] <TabAtkins> TabAtkins: That's a problem if we add a new property that matches a common author keyframe.
622. # [20:16] <anne> to disambiguate you could use keyframe(<ident>)
623. # [20:17] <ChrisL> well, a keyframe name could have some syntax to always identify it. $keyframe or something
624. # [20:17] <TabAtkins> szilles: [talks about animations as a restricted subset of transitions, or viceversa]
625. # [20:17] <TabAtkins> dean: A transition could be considered an animation that's created automatically at the moment of the property change.
626. # [20:18] <TabAtkins> dean: That automatically fills in the start and end, and automatically removes itself at the end.
627. # [20:18] <TabAtkins> dean: We're not just concerned about the impl difficulty here, but about authoring simplicity, and that's definitely why we did them differently. But we'll try.
628. # [20:19] <TabAtkins> glazou: If you take the animation example, and remove the "from", it's equivalent to a transition.
629. # [20:19] <Bert> q+ to suggest 'transition-PLAY-count' instead of -ITERATION-, to match 'marquee-play-count'
630. # [20:20] <TabAtkins> dean: Not quite. Even if you remove the "from" and the "end", you're still saying you want a pulse, and there's nothing left to say what is being transitioned.
631. # [20:21] <TabAtkins> howcome: [doesn't like the names "Transition" and "Transform" being so close]
632. # [20:21] <bradk> trans(form|ition):
633. # [20:22] <TabAtkins> trans(former): robots-in-disguise;
634. # [20:22] <TabAtkins> [naming talk]
635. # [20:23] <bradk> metamorphosis-timing-function:
636. # [20:23] <TabAtkins> ChrisL: If you think of transitions as syntax sugar for an animation that is automatically created, it seems you can harmonize it.
637. # [20:24] * Quits: dino (dino@17.244.0.152) (Quit: dino)
638. # [20:24] <TabAtkins> glazou: The discussion was not about naming. It was about harmonizing transitions and animations.
639. # [20:24] <TabAtkins> dean: Ultimately what dbaron proposed is easy to implement; just merge all the properties together and have some way of telling apart transitions and animations.
640. # [20:25] <TabAtkins> dean: But I want to go back and look at content we have and see if this sort of change will make it easier or harder to write.
641. # [20:26] <TabAtkins> tantek: How many people have authored this on the public web? I found it confusing immediately, but as soon as I worked with it for a little bit it became very clear.
642. # [20:27] <TabAtkins> howcome: I had the opposite.
643. # [20:27] <TabAtkins> dbaron: I said I was in the middle before, now I'm leaning toward dean.
644. # [20:28] <tantek> transform makes sense from a mathematical functional sense
645. # [20:28] <TabAtkins> plinss: It is possible to make a superset, the question is if it will help.
646. # [20:29] <tantek> http://en.wikipedia.org/wiki/List_of_transforms
647. # [20:30] <TabAtkins> dean: A weird thing if you combine them is that you can have a transition and an animation both controlling the same thing they'll fight.
648. # [20:31] <tantek> whereas transition makes sense like "state transition" in science/chemistry/physics
649. # [20:31] <TabAtkins> glazou: I think you can possibly combine them, but at the cost of more complex syntax.
650. # [20:31] <tantek> http://en.wikipedia.org/wiki/Transition_state
651. # [20:31] * Quits: dbaron (dbaron@17.244.2.46) (Quit: 8403864 bytes have been tenured, next gc will be global.)
652. # [20:31] <TabAtkins> glazou: I gave a demo with transitions and everyone got it immediately.
653. # [20:31] <TabAtkins> howcome: I think we need to try to *look* at the issue.
654. # [20:32] <TabAtkins> glazou: Sure, if someone can pull out a new proposal, great, but don't block the existing draft on it.
655. # [20:32] <TabAtkins> howcome: I think this problem [referring to the example with reversing an animation] needs to be solved.
656. # [20:32] <TabAtkins> plinss: Everyone agrees that that's a problem to be solved, but it's separate from this issue.
657. # [20:33] <TabAtkins> howcome: I'm happy to go away and see if I can come up with something smart, or if others can.
658. # [20:33] <TabAtkins> howcome: But also I'd like an action on the spec editors to deal with the reversible animation. This was the first simple thing I ran into that I thought I should be able to do.
659. # [20:34] <TabAtkins> tantek: I think this should be logged as an apparent hole, and I'm interested in Dean's input on other apparent holes .
660. # [20:34] <TabAtkins> dean: [talk about fill modes being added in nightlies]
661. # [20:34] <Bert> (One thing I don't understand about animations and transitions is how you can have both: an object ca only be in one place at one time (Heisenberg notwithstanding).)
662. # [20:35] <TabAtkins> ChrisL: Oh, you didn't have that? Definitely, that's necessary.
663. # [20:35] <TabAtkins> dean: Yeah, it prevents a lot of added complexity.
664. # [20:35] <TabAtkins> dean: All the holes are trying to avoid writing script.
665. # [20:35] <TabAtkins> dean: So another one is how to chain animations.
666. # [20:35] <ChrisL> Having fill mode is crucial. smil has post-animation fill, only. pre-animation fill is a useful addition
667. # [20:36] <TabAtkins> dean: So maybe say the end-time of one transition is the start of another.
668. # [20:37] <TabAtkins> ChrisL: So you can have animations keyed by a transition? Looks like that would solve the example problem.
669. # [20:37] <TabAtkins> smfr: ONe thing I'd like to have is for the keyframes to apply with the same specificity as the selector, as if they're sucked into the declaration block and can be overriden.
670. # [20:37] <TabAtkins> dean: We'd known about these things for a while, we just didn't put them in the proposal so we could have sometehing out in a reaonable time.
671. # [20:38] <TabAtkins> dean: Another is, if you have multiple transitions together, the latest one wins. We'd like to be able to combine animations without explicitly writing them together in a keyframe rule.
672. # [20:39] <TabAtkins> ChrisL: That seems crucial; you often want to run two animations that are simple by themselves but are rather complex to specify togethere.
673. # [20:39] <TabAtkins> Bert: Had a question about the name of one property - iteration-count.
674. # [20:40] <TabAtkins> Bert: But when we discussed marquee, Molly argued forcefully for play-count. Perhaps we can use the same type of name.
675. # [20:41] <TabAtkins> TabAtkins: I agree; I think it's shorter, easier to type, and jives with marquee's similar property.
676. # [20:42] <TabAtkins> fantasai: What about tantek's suggestion to change animation-duration to animation-period?
677. # [20:42] <TabAtkins> glazou: we need to close this for now.
678. # [20:42] * Joins: dbaron (dbaron@63.245.220.11)
679. # [20:42] <TabAtkins> ACTION: howcome to produce alternate proposal for handling animation and transition together
680. # [20:42] * trackbot noticed an ACTION. Trying to create it.
681. # [20:42] * RRSAgent records action 5
682. # [20:42] <trackbot> Created ACTION-213 - Produce alternate proposal for handling animation and transition together [on Håkon Wium Lie - due 2010-04-06].
683. # [20:43] <dbaron> What about repeat-count rather than play-count or iteration-count?
684. # [20:43] <Bert> (Also 'marquee-direction' and 'animation-direction' are subtly different, but I haven't understood what the difference is yet...)
685. # [20:43] <TabAtkins> glazou: Steps to advance transitions
686. # [20:44] <TabAtkins> smfr: We'll add stepwise functions, and publish a new draft.
687. # [20:44] <TabAtkins> dbaron: I think we also need to handle the reversing business, and probably the details in the "animation of property types" section. I've been guilty of not sending comments about that.
688. # [20:45] <TabAtkins> dean: Can we settle on a goal for progressing to Last Call?
689. # [20:45] <TabAtkins> dbaron: I think it's doable to do LC in a few months.
690. # [20:45] <TabAtkins> tantek: Is there an issues page for this draft?
691. # [20:46] <TabAtkins> dbaron: I created an issues page, but didn't add anything to it for a while.
692. # [20:46] <TabAtkins> fantasai: Editors should be making the issues list.
693. # [20:47] <TabAtkins> ACTION: dean and smfr to produce issues list for Transitions and Animations, including comments from dbaron and howcome.
694. # [20:47] * trackbot noticed an ACTION. Trying to create it.
695. # [20:47] * RRSAgent records action 6
696. # [20:47] <trackbot> Created ACTION-214 - And smfr to produce issues list for Transitions and Animations, including comments from dbaron and howcome. [on Dean Jackson - due 2010-04-06].
697. # [20:47] <Bert> -> http://www.w3.org/Style/CSS/Tracker/products/22 issues list for transitions (only has one issue currently)
698. # [20:48] <TabAtkins> [discussion of testing transitions/animations]
699. # [20:49] <glazou> transition-workin-group: lunch pulse 3mn
700. # [20:50] * Quits: smfr (smfr@17.244.1.194) (Quit: smfr)
701. # [20:50] * Quits: dethbakin (dethbakin@17.244.0.186) (Quit: dethbakin)
702. # [20:50] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
703. # [20:50] * Quits: bradk (bradk@17.244.0.81) (Quit: Computer has gone to sleep)
704. # [20:50] * Quits: tantek (tantek@173.147.183.213) (Quit: tantek)
705. # [20:52] * Quits: sylvaing (sylvaing@17.244.0.225) (Ping timeout)
706. # [20:52] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
707. # [20:52] * Quits: Arron (arronei@17.244.2.216) (Ping timeout)
708. # [20:53] * Quits: TabAtkins (chatzilla@17.244.2.48) (Ping timeout)
709. # [21:35] * Joins: jdaggett_ (jdaggett@110.4.186.83)
710. # [21:36] * Quits: jdaggett_ (jdaggett@110.4.186.83) (Quit: jdaggett_)
711. # [21:36] * Joins: jdaggett_ (jdaggett@110.4.186.83)
712. # [21:36] * Parts: jdaggett_ (jdaggett@110.4.186.83)
713. # [21:36] * Joins: jdaggett_ (jdaggett@110.4.186.83)
714. # [21:37] * jdaggett_ is now known as wombat99
715. # [21:41] * Joins: jdaggett (jdaggett@110.4.186.83)
716. # [21:46] * Joins: Arron (arronei@17.244.2.216)
717. # [21:47] * Joins: dethbakin (dethbakin@17.244.1.101)
718. # [21:47] * Quits: dethbakin (dethbakin@17.244.1.101) (Quit: dethbakin)
719. # [21:47] * Joins: TabAtkins (chatzilla@17.244.2.48)
720. # [21:48] * CSS-projector wonders where my lunch is
721. # [21:49] * Joins: bradk (bradk@17.244.0.81)
722. # [21:49] * Joins: szilles (chatzilla@17.244.3.121)
723. # [21:51] * Joins: dsinger (dsinger@17.244.1.88)
724. # [21:51] * Joins: dino (dino@17.202.116.62)
725. # [21:52] * Joins: sylvaing (sylvaing@17.244.2.236)
726. # [21:52] * Joins: Zakim (rrs-bridgg@128.30.52.169)
727. # [21:52] <dino> zakim, list conferences
728. # [21:52] <Zakim> I see Team_MIT(SITE)2:30PM, WS_WSRA()3:30PM active
729. # [21:52] <Zakim> also scheduled at this time are GA_(Effects TF)3:00PM, INC_SSN()4:00PM
730. # [21:52] * dbaron RRSAgent, pointer?
731. # [21:52] * RRSAgent See http://www.w3.org/2010/03/29-CSS-irc#T19-50-24
732. # [21:52] * Joins: smfr (smfr@17.244.1.194)
733. # [21:53] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
734. # [21:54] * Joins: glazou (glazou@17.244.0.83)
735. # [21:56] * Joins: tantek (tantek@173.147.183.213)
736. # [21:57] * Joins: dethbakin (dethbakin@17.244.1.101)
737. # [21:59] <dino> zakim, room for 5?
738. # [21:59] <Zakim> ok, dino; conference Team_(css)19:57Z scheduled with code 26631 (CONF1) for 60 minutes until 2057Z
739. # [22:00] * dsinger we're discussing http://www.dbaron.org/mozilla/visited-privacy
740. # [22:00] * dino plinss see conference code above - 26631
741. # [22:01] <ChrisL> s/ http://www.dbaron.org/mozilla/visited-privacy/a mozilla proposal/
742. # [22:03] * ChrisL rrsagent, here
743. # [22:03] * RRSAgent See http://www.w3.org/2010/03/29-CSS-irc#T19-59-14
744. # [22:07] <jdaggett> dino: so the dial-in number is the normal zakim number, then 26631?
745. # [22:07] <dino> jdaggett: yes
746. # [22:08] <jdaggett> great
747. # [22:08] <glazou> hi jdaggett
748. # [22:08] <dino> jdaggett: i'm not in the meeting room so I don't know if they have dialed yet
749. # [22:08] <glazou> not yet
750. # [22:08] <jdaggett> ok
751. # [22:08] <glazou> dbaron still speaking
752. # [22:08] <ChrisL> they haven't
753. # [22:09] <glazou> jdaggett: we have only one pod, so LOUD voice will be useful
754. # [22:09] <jdaggett> ok, will be a big mouth today
755. # [22:09] <glazou> Zakim, code ?
756. # [22:09] <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), glazou
757. # [22:09] <jdaggett> my guess is i'll miss some of the mumbling that goes on
758. # [22:10] <glazou> probably yes
759. # [22:10] <glazou> we'll gather around the pod
760. # [22:10] <glazou> jdaggett: calling now
761. # [22:10] * Joins: jfkthame (jonathan@95.150.118.177)
762. # [22:11] <Zakim> Team_(css)19:57Z has now started
763. # [22:11] <Zakim> +[IPcaller]
764. # [22:11] <Zakim> +[Apple]
765. # [22:11] <fantasai> ScribeNick: fantasai
766. # [22:11] <jdaggett> ipcaller is jdaggett
767. # [22:11] <fantasai> jdaggett joins from Tokyo via phone bridge
768. # [22:12] <jdaggett> zakim, ipcaller is jdaggett
769. # [22:12] <Zakim> +jdaggett; got it
770. # [22:12] <fantasai> testing voice range of mic
771. # [22:12] <Zakim> + +44.845.397.aaaa
772. # [22:12] <dbaron> Zakim, aaaa is jfkthame
773. # [22:12] <Zakim> +jfkthame; got it
774. # [22:12] <fantasai> Jonathan Kew has just joined
775. # [22:12] * dbaron Zakim, who is on the phone?
776. # [22:13] * Zakim sees on the phone: jdaggett, [Apple], jfkthame
777. # [22:13] <fantasai> jdaggett: I wanted to go over one thing that was discussed yesterday
778. # [22:13] * Quits: smfr (smfr@17.244.1.194) (Quit: smfr)
779. # [22:13] <fantasai> jdaggett: There was the question of CSS2.1 font-weight
780. # [22:13] * Joins: szilles (chatzilla@17.244.3.121)
781. # [22:13] * Joins: cslye (cslye@17.244.3.65)
782. # [22:13] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0510.html
783. # [22:14] <fantasai> jdaggett: The wording of the 2.1 spec now, the 4 bullet points you guys were talking about
784. # [22:14] <fantasai> jdaggett: The 4th bullet point is not clear about 400 and 500
785. # [22:14] <fantasai> jdaggett: It's clear in case where 400 doesn't exist but 500 does, but not about other cases
786. # [22:14] <fantasai> jdaggett: I've clarified this in css3-fonts
787. # [22:15] <fantasai> Chris: In that case I suggest we adopt the CSS3 wording in CSS2.1 to keep these consistent
788. # [22:15] * Joins: mjs (mjs@17.203.15.150)
789. # [22:15] <fantasai> jdaggett: basically 400 and 500 map to each other, and then they map down
790. # [22:15] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0279.html
791. # [22:16] <fantasai> RESOLVED: accept proposal to use css3-fonts wording about font-weight hole-filling in css2.1
792. # [22:16] <fantasai> jdaggett: ? posted about having an all-small-caps setting
793. # [22:16] <fantasai> jdaggett: It's very easy to add, I've added it to the current wording
794. # [22:16] <TabAtkins> s/?/Adam Twardoch (sp?)/
795. # [22:16] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-caps-prop
796. # [22:17] <fantasai> jdaggett: The one tricky part about this is because of the bheavior defined in 2.1 for small caps, where UAs fake small caps,
797. # [22:17] <fantasai> jdaggett: to be compatible with 2.1 we need to continue to fake that behavior
798. # [22:18] <fantasai> jdaggett: I don't think this would work for petite-caps, so I didn't add simulation there
799. # [22:18] <fantasai> jdaggett: Because they are much smaller, and the size difference would be noticeable
800. # [22:19] <fantasai> Chris: So what you're talking about is fallback. I think you're correct that leaving petite-caps as lowercase is better than faking small-caps
801. # [22:19] * Joins: smfr (smfr@17.203.14.12)
802. # [22:19] <fantasai> jdaggett: So to summarize, we will fake small-caps and all-small-caps, but not petite-caps or all-petite-caps
803. # [22:19] <fantasai> howcome: Isn't all-small-caps the same as text-transform + small-caps?
804. # [22:20] <fantasai> jdaggett: It's very close, but since you're doing the casing in the font engine, the font can tweak things like parentheses because it knows there are no lowercase letters
805. # [22:20] <fantasai> howcome: Wouldn't it make sense to do the higher-quality rendering for text-transform + small caps as well?
806. # [22:21] <fantasai> jdaggett: You're not communicating to the opentype engine that it's all small caps
807. # [22:21] <fantasai> howcome: You could, though. If you know tet-transform: lowercase is applied, then you know that it's the same as all-small caps and you can request that from the engine
808. # [22:23] <fantasai> jdaggett: Adam posted an explanation explaining the rendering of text that has already been transforming
809. # [22:23] <fantasai> jdaggett: ... something about not knowing when things get transformed
810. # [22:24] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0306.html
811. # [22:24] <fantasai> cslye: I do think some font developers do put extra stuff in these layout features, like numbers and currency
812. # [22:25] <fantasai> cslye: I don't know if it's good or bad, but some people use this as a way to pack more into a font. It's not just letters transforming, but an alternate look
813. # [22:26] <fantasai> jdaggett: I think what howcome is saying is that instead of the author explicitly requesting all-small-caps, the feature would be implied by a combination of CSS properties
814. # [22:26] <fantasai> ...
815. # [22:26] <fantasai> Steve: howcome's saying that affter you've done the transformation, you remember that fact, and then you pick up the c2sc
816. # [22:26] <fantasai> jdaggett: I think the implementation would be tricky because you'd have to see if the font has this feature enabled. *If* not, then you do the transformation yourself
817. # [22:27] <fantasai> cslye: Is it intuitive to split this? If you have an acronym, you usually want to transform to uppercase, then use all-small-caps to get a smaller version if that's available
818. # [22:27] <fantasai> cslye: Not to use a lowercase version
819. # [22:28] <fantasai> jdaggett: ... petite-caps is a different route than lowercasing and then petitecaps
820. # [22:29] <fantasai> howcome: I think that keyword is not necessary, so I would like to see this marked as an issue
821. # [22:29] <fantasai> Steve: My question is what is easier for the user
822. # [22:29] <fantasai> cslye: I think Adam addresses this in his email
823. # [22:30] <fantasai> Steve: What's the computed value?
824. # [22:31] <fantasai> ChrisL: What you get by copy-paste after transformation varies by UA
825. # [22:32] <fantasai> ...
826. # [22:32] <fantasai> Steve: If you want to use text-transform selectively, then all-small-caps is a better option
827. # [22:33] * Quits: mjs (mjs@17.203.15.150) (Connection reset by peer)
828. # [22:33] <fantasai> ChrisL: If a user agent understands and sees this combination of properties, it could hand off the combination to the font engine and ask it to do it all
829. # [22:33] * Joins: mjs (mjs@17.203.15.150)
830. # [22:33] <fantasai> Steve: The scope of the text-transform is different from the scope of the all-small-caps
831. # [22:34] <fantasai> dsinger: If you have a way of asking the font engine to do something directly, and you use a circuitous route, you should get different results
832. # [22:34] <fantasai> Bert: Shouldn't have two ways to do two things that are so closely related
833. # [22:35] <fantasai> Bert: We already have one way to get there
834. # [22:36] <fantasai> Bert: And the difference between the two is very subtle, most people won't notice but one way is definitely better
835. # [22:37] <fantasai> cslye: Our concern is that text-transform + small-caps is unintuitive
836. # [22:37] <fantasai> jdaggett: Sounds like we dont' have a conclusion, but we should keep track of the issue
837. # [22:37] <fantasai> SteveZ: you can put an issue in the draft
838. # [22:37] <fantasai> jdaggett: I will mark this as an issue, and the maybe ping Adam again
839. # [22:38] <fantasai> howcome: It's the same issue for all-petite-caps, too
840. # [22:39] <fantasai> fantasai: The fallback for petite-caps doesn't involve synthesis, so you could wind up with all lower case instead
841. # [22:39] <fantasai> fantasai: at least for small caps + text transform, you're guaranteed small caps even if they're not as pretty
842. # [22:39] <fantasai> Bert: Maybe the fallback for petite-caps should be small-caps?
843. # [22:39] <fantasai> cslye: It's a good question
844. # [22:40] <fantasai> cslye: Maybe you're better off faking petite-caps
845. # [22:40] <fantasai> jdaggett: I don't think we should have UAs fake the petite-caps
846. # [22:40] <fantasai> SteveZ: Which is why I suggest falling back to small-caps
847. # [22:41] <fantasai> jdaggett: I don't think it will work
848. # [22:41] <fantasai> jdaggett: The feature becomes so subtle, that ...
849. # [22:41] <fantasai> howcome: No this, is just to ensure that we can implement this in a non-OT environment as well
850. # [22:41] <fantasai> howcome: so that UAs in those environments can do something there
851. # [22:42] <fantasai> jdaggett: When you try to synthesize petite caps, the glyphs get so small that it's hard to read
852. # [22:42] <bradk> faked petite caps would look too fake and too light. Small caps/fake small caps would be a better falback.
853. # [22:42] * fantasai agrees with bradk
854. # [22:43] <fantasai> jdaggett and dsinger think this is a slippery slope
855. # [22:43] <fantasai> jdaggett: I think going in this direction is diminishing returns
856. # [22:43] * Bert agress as well: petite caps look much more like small-caps than like lowercase.
857. # [22:45] <jfkthame> using small-caps as the fallback for petite-caps makes sense .... like we use oblique as fallback for italic (or vice versa)
858. # [22:46] <fantasai> jdaggett: I would like to avoid artificial ways of doing font feature effects
859. # [22:47] <fantasai> cslye: That's fine, but then we can't implement the all-petite-caps feature with text-transform, because we'll wind up with unwanted lowercase
860. # [22:47] <fantasai> jdaggett: Ok, I'm going to record this as there are two separate but possibly related issues
861. # [22:47] <fantasai> SteveZ: Another point to record is that, it appears that some people believe petite-caps match the x-height of the font
862. # [22:48] <fantasai> SteveZ: And in fact in one place, they were called ex-caps
863. # [22:48] <fantasai> jdaggett: Petite-caps are below the x-height.
864. # [22:48] <fantasai> cslye and stevez don't agree
865. # [22:48] <fantasai> jdaggett: It's smaller than small-caps
866. # [22:48] <bradk> 'text-transform:lowercase;' + small caps = all small caps seems ituitive to me.
867. # [22:48] <fantasai> SteveZ: small-caps are typically above the x-height
868. # [22:49] <fantasai> jdaggett: next issue
869. # [22:49] <fantasai> jdaggett: Dealing with subscript and superscript
870. # [22:49] <fantasai> jdaggett: OT has features that allow font designers to put sub /super glyphs in the font itself
871. # [22:49] <fantasai> jdaggett: Issue is how to access it
872. # [22:49] <bradk> 'text-transform:lowercase; + all-small-caps = all-small-caps seems like a waste of a property
873. # [22:49] <fantasai> jdaggett: currently sub/super is done with a combination of properties
874. # [22:50] <fantasai> jdaggett: the question is how to work things so that use the font feature if available, otherwise fall back to altering properties as before
875. # [22:50] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0245.html
876. # [22:50] <fantasai> jdaggett: that's the original issue
877. # [22:50] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#character-transform-prop
878. # [22:50] <fantasai> jdaggett: This is how the spec currently words it
879. # [22:51] <fantasai> jdaggett: the idea here is that you use the subscript glyph if available,
880. # [22:51] <fantasai> jdaggett: and fall back to a synthesized version of that if that's not available
881. # [22:51] <howcome> http://people.opera.com/howcome/2010/tests/petite.html
882. # [22:51] <fantasai> jdaggett: and in this case I think it's better that the author see a simulated version
883. # [22:52] <fantasai> ChrisL: Yes, this is good, because the fallback and the feature don't get combined
884. # [22:52] <fantasai> ChrisL: It's a little weird that it resets the properties it simulates with, but I also think it's a good idea here.
885. # [22:53] <fantasai> SteveZ: What happens if I stack superscripts or stack subscripts?
886. # [22:53] <fantasai> SteveZ: This is common in mathematics
887. # [22:53] <dbaron> We probably don't want to break 2^{2^x}
888. # [22:53] <fantasai> SteveZ: The reason I say super { font-size: 70% } is so that stacking superscripts works
889. # [22:54] <fantasai> Bert: It seems to me that we're using a feature in OT that we already have
890. # [22:54] <fantasai> SteveZ: We don't already have this. Simulated supserscripts are not nearly as correct typographically as real ones
891. # [22:55] <fantasai> jdaggett asserts that stacked subscripts are unusual
892. # [22:55] <fantasai> SteveZ and ChrisL disagree, it is a common case
893. # [22:56] * Quits: cslye (cslye@17.244.3.65) (Quit: cslye)
894. # [22:56] <fantasai> you probably don't want character-transform to inherit...
895. # [22:57] * Joins: cslye (cslye@17.244.3.65)
896. # [22:57] <fantasai> jdaggett: the subscript or superscript is tied to a base font size
897. # [22:57] <fantasai> jdaggett: changing the font size changes the color of the glyph
898. # [22:58] <fantasai> jdaggett argues against something
899. # [22:58] <fantasai> Steve: Let me try another way
900. # [22:58] <fantasai> Steve: What I'm trying to get at is, the user decreased the font size
901. # [22:59] <fantasai> Steve: One way to deal with this is to reset the font size
902. # [22:59] <fantasai> Steve: The other way is to not reset the font size, but to use the font-size of the parent when selecting the superscript glyph
903. # [22:59] <fantasai> fantasai: The tricky part is, if you have nested elements, you don't want the parent
904. # [22:59] <Bert> (But then the author doesn't get what he asked for, does he?)
905. # [23:00] <ChrisL> s/common case/common case in mathematics/
906. # [23:00] <fantasai> fantasai: you want the parent of the element on which character-transform was set
907. # [23:00] <fantasai> Steve: That would allow us to get nice superscripts all the way down
908. # [23:00] <fantasai> jdaggett: I think I understand what you're trying to say
909. # [23:00] <fantasai> jdaggett: I can see these two things being used in conjunction. Whatever it is, though, it should be understandable in the simple case
910. # [23:01] <fantasai> Steve: The simple case, they'll look exactly the same, so it didnt' really matter which way you did it
911. # [23:01] <fantasai> Steve: The result is you would use the subscript character in the size of the original font
912. # [23:01] <fantasai> jdaggett: As long as that's there, that's the key thing
913. # [23:03] <fantasai> Chris and Steve try to explain the use case for character-transform to Bert
914. # [23:03] <fantasai> Bert: What if there's an image in there? Or fallback fonts?
915. # [23:03] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
916. # [23:04] <fantasai> jdaggett: This is something that would make sense for the default behavior, but it doesn't make it impossible to use the old behavior
917. # [23:05] <fantasai> fantasai: Bert has a good point. If you have fallback, or if you have images, you don't know where the effective baseline is
918. # [23:05] <fantasai> fantasai: And you can't align things to it
919. # [23:06] <fantasai> SteveZ: In that case, you could say, if there is anything in the element that can't be substituted through the font, then you fake the whole thing
920. # [23:06] <fantasai> jdaggett: I don't think you can do that
921. # [23:06] <fantasai> jdaggett: I don't think it's practical to make the fallback behavior contextual
922. # [23:06] <fantasai> jdaggett: You're either affecting vertical-align or you're not
923. # [23:07] <fantasai> jdaggett: We have to know
924. # [23:07] <fantasai> SteveZ: my approach is that you odn't affect font-size or vertical-align when you do this
925. # [23:07] <fantasai> SteveZ: You just don't use them when rendering
926. # [23:07] <fantasai> ChrisL: I like that approach
927. # [23:07] <fantasai> peter says something quietly
928. # [23:08] <jfkthame> if you're applying an opentype superscript or subscript feature, and you need to know the baseline for some other alignment, you can ask the font for its superscript or subscript offset
929. # [23:08] <fantasai> jdaggett: I'm not crystal clear on what is being proposed, so what I'd ask you to do is to look at 6.2 and suggest specific changes
930. # [23:08] <fantasai> ACTION: SteveZ Propose changes to character-transform to address above concerns
931. # [23:08] * trackbot noticed an ACTION. Trying to create it.
932. # [23:08] * RRSAgent records action 7
933. # [23:08] <trackbot> Created ACTION-215 - Propose changes to character-transform to address above concerns [on Steve Zilles - due 2010-04-06].
934. # [23:08] <fantasai> jfkthame, thanks!
935. # [23:08] <fantasai> jdaggett: new topic
936. # [23:08] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0224.html
937. # [23:08] <fantasai> jdaggett: Talking about font-specific font features
938. # [23:08] <jdaggett> http://people.mozilla.org/~jdaggett/images/fallbackexamples.png
939. # [23:09] <fantasai> jdaggett: In the first page you have, say, two fonts
940. # [23:09] <fantasai> jdaggett: If you use the setting styleset(6), that's picking a specific font feature
941. # [23:10] <fantasai> jdaggett: typically styleset numbers' effect is not consistent across fonts
942. # [23:10] <fantasai> jdaggett: Last time we talked about this, there were a number of people were concerned that triggering a numbered styleset across font would not be good
943. # [23:10] <fantasai> jdaggett: The key point here is that htese are variations on the underlying font itself
944. # [23:10] <fantasai> jdaggett: they're not .. look coherent with the text that surrounds it
945. # [23:11] <fantasai> jdaggett: The concern about showing some crazy glyph.. that the resulting fallback will be ruinous
946. # [23:11] <fantasai> jdaggett: I think that's really far-fetched scenario
947. # [23:11] <fantasai> jdaggett: You'd have to have a pathological fallback situation for that to happen
948. # [23:11] <fantasai> jdaggett: Most platform fonts dont' have this feature, and they tend to be subtle
949. # [23:11] <fantasai> jdaggett: Authors would have to not know about (?)
950. # [23:12] <dsinger> is that (a) because fallback etc. is unlikely or (b) because styleset(6) (say) is likely to be there or not, but not very 'different' between fonts?
951. # [23:12] <jdaggett> http://people.mozilla.org/~jdaggett/tests/strangepresentationalligs.html
952. # [23:12] <jdaggett> http://people.mozilla.org/~jdaggett/tests/strangeligatures.png
953. # [23:12] <fantasai> on the left is safari, on the right is firefox
954. # [23:13] <dsinger> isn't it possible that styleset(6) in one font gives me a variant designed for great legibility at small sizes and in another, designed for swishy presentation in titling and at large sizes?
955. # [23:13] <fantasai> ChrisL: Could I interject an observation?
956. # [23:13] <fantasai> ChrisL: I think there's not very many of these ligatures
957. # [23:13] <fantasai> ChrisL: They're added mainly for codepage roundtripping between legacy encodings
958. # [23:14] <fantasai> ChrisL: They tend not to be supported in fonts
959. # [23:14] <fantasai> ChrisL: And they mess up other things like searching
960. # [23:14] <fantasai> ChrisL: As long as people have a more reliable method of getting the same effect
961. # [23:14] <fantasai> ChrisL: I think the use of these presentation ligature codepoints will be decrease
962. # [23:15] <fantasai> jdaggett: My comment isn't about whether they should be used, but that their fallback is different
963. # [23:15] <fantasai> jdaggett: My point is that when fallback occurs, strange things can occur
964. # [23:15] <fantasai> dsinger projects his comment into voice
965. # [23:16] <fantasai> dsinger: Style sets should be only applied to the font for which they're expected to apply
966. # [23:16] <fantasai> jdaggett: That's what you get with fallback.
967. # [23:16] <jfkthame> it's possible, but a very unlikely scenario - font features are the wrong mechanism for a designer to be using there, that's optical sizing
968. # [23:16] <fantasai> dsinger: Why do we wind up speciying a font-specific setting to a fallback font?
969. # [23:16] <fantasai> dsinger: Why don't we design the syntax so you only apply the font-specific setting to the font it was intended for/
970. # [23:16] <fantasai> jdaggett: styleset is the most extreme example
971. # [23:17] <fantasai> jdaggett: but some other features may or may not be font specific
972. # [23:17] <fantasai> jdaggett: e.g. the annotation forms feature
973. # [23:17] <jfkthame> styleset may well behave consistently across a whole library of fonts, e.g., from a single designer/vendor
974. # [23:17] <fantasai> http://people.mozilla.org/~jdaggett/images/fallbackexamples.png
975. # [23:17] <fantasai> jdaggett: There is more consistency there
976. # [23:18] <fantasai> jdaggett: The author should be making the decision of whether it's a font-specific or font-generic feature.
977. # [23:18] <fantasai> ChrisL: One way to get around this is to put the style set selection in the @font-face rule
978. # [23:18] * fantasai missed ChrisL 's comment
979. # [23:19] <fantasai> dsinger: Note also that the font that ends up being used might be something the author didn't select at all. It could be something specified by the user.
980. # [23:19] <fantasai> or on a system with limited fonts and no downloading
981. # [23:19] <fantasai> Steve: I may, with old eyes, want to use a high-contrast font
982. # [23:19] <ChrisL> While it may be sometimes true, or indeed often true, that opentype font features only make sense when applied to a specific font or to a spacific family, it is not clear that it is *always* true
983. # [23:19] <ChrisL> nd thus, authors should be able to choose whether to make this general or font specific.
984. # [23:20] <fantasai> jdaggett: You can't guarantee that the web page is readable with an alternate font
985. # [23:20] <jfkthame> if you want to use a personal stylesheet to force a certain font, you can also use it to override the features
986. # [23:20] <fantasai> jdaggett: The author could pick a set of CSS features in combination that would make the page unreadable with another font
987. # [23:20] <fantasai> dsinger: I'm not saying that all font features should be restricted
988. # [23:21] <fantasai> dsinger: But the ones where you're selecting by number, rather than by name for a generic feature, you're getting a random effect if you're getting one at all
989. # [23:21] <fantasai> dsinger: That doesn't seem right to me
990. # [23:21] <fantasai> jdaggett: You can already use @font-face if you really want
991. # [23:21] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Mar/0202.html
992. # [23:22] <fantasai> jdaggett argues that this and that is not that font-specific
993. # [23:23] <fantasai> peter: The problem is that the author may think that the feature is not font-specific, and they test it on their three fonts, but then some user 5 years downt he line uses a font that the author never expected
994. # [23:23] <fantasai> jdaggett: We're not changing the characters, we're changing the presentation
995. # [23:23] <fantasai> dsinger: styleset(6) doesn't say what the change in presentation is, and it might be very specific to the font
996. # [23:24] <fantasai> ...
997. # [23:24] <Arron> font-variant: styleset(gabriola, 6) styleset("poetica std", 3);
998. # [23:24] <fantasai> howcome: Couldn't we just say that the styleset(6) applies only to the first font in the list
999. # [23:24] <fantasai> howcome: and if you want to set it on other things, then you set it on @font-face
1000. # [23:24] * dsinger I also suggested what Arron typed :-)
1001. # [23:25] <fantasai> jdaggett: If we come up with clever syntax to make it font-specific, we increase the burden of the author
1002. # [23:26] <fantasai> howcome: We increase the burden on the author to decrease the chance of something weird happening
1003. # [23:26] <fantasai> Peter: Authors' aren't going to read the standard, and they're not going to know whether they should use it in the property or in the @font-face
1004. # [23:27] <fantasai> Peter: It's going to work fine on their machine, and then the reader gets screwed down the line
1005. # [23:27] <fantasai> jdaggett: It won't be unreadable
1006. # [23:27] <fantasai> dsinger: If it were designed for 30pts in titles adn gets used in body text, then you might well get something unreadable
1007. # [23:28] <fantasai> cslye: ... throwing baby out with the bath water
1008. # [23:29] <fantasai> peter: We're not saying let's not have this feature
1009. # [23:29] <fantasai> fantasai: It's not that hard to tie the feature to the font. We have at least 3 proposed ways to do it
1010. # [23:30] <dsinger> I would prefer syntax that makes it unlikely, I would settle for a warning...
1011. # [23:30] <fantasai> jdaggett: I think whether something is font-specific or not is not determined by whether it's numerical or not
1012. # [23:30] <fantasai> dsinger: Yes, I accept a given foundry may use numbers consistently across fonts
1013. # [23:31] <fantasai> jdaggett: I think authors should have this flexibility
1014. # [23:31] <fantasai> We're not moving forward with this :(
1015. # [23:31] <fantasai> jdaggett: The other issue was font-size-adjust
1016. # [23:32] <fantasai> jdaggett: I'm not sure I would be the best rep for that issue
1017. # [23:32] <fantasai> dbaron takes the floor
1018. # [23:32] <fantasai> dbaron: The idea of font-size-adjust is that it's a way of specifying the font size by specifying the x-height
1019. # [23:32] <fantasai> dbaron: it does it in backwards-compatible way so that old UAs get the font-size property
1020. # [23:32] <fantasai> dbaron: It does this by having font-size-adjust take a number
1021. # [23:33] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-size-adjust-prop
1022. # [23:33] <fantasai> dbaron: font-size: 20px; font-size-adjust: 0.45; gets you 9px x-height
1023. # [23:33] <fantasai> dbaron: this is useful for two things
1024. # [23:33] * Joins: Curt` (DorkeyDear@76.241.90.62)
1025. # [23:33] <jdaggett> example of how font-size-adjust works
1026. # [23:33] <jdaggett> http://dev.w3.org/csswg/css3-fonts/fontsizeadjust.png
1027. # [23:33] <fantasai> dbaron: Particularly at small font size [in bicameral scripts], legibility is related more to x-height than to font size
1028. # [23:33] <ChrisL> and this is primarily useful when fonts are substituted, or changed on sub elements
1029. # [23:33] <fantasai> dbaron: e.g. Verdana is readable at very small font sizes
1030. # [23:34] <fantasai> even though most fonts are not
1031. # [23:34] <fantasai> dbaron: One use case for font-size-adjust is when you have multiple fonts
1032. # [23:34] <fantasai> dbaron: E.g. in computer docs, you are mixing normal font with monospace font
1033. # [23:34] <fantasai> dbaron: and depending ont eh fonts, the x-heights might be very different
1034. # [23:35] <fantasai> dbaron: So to get a consistent effective size, you'd need to size them differently (e.g. much smaller monospace font)
1035. # [23:35] <Bert> s/ont eh/on the/
1036. # [23:35] <fantasai> dbaron: I wanted to make font-size-adjust work better in cases where the author wants to use the user's default font size
1037. # [23:35] <fantasai> dbaron: but still equalize x-heights across fonts
1038. # [23:35] <bradk> example of tiny x-height: http://www.fonts.com/FindFonts/detail.htm?pid=203205
1039. # [23:36] <fantasai> dbaron: The secondary use case is that browsers do really weird things to equalize proportional and monospace fonts
1040. # [23:36] <fantasai> dbaron: and this couldpotentially replace that
1041. # [23:36] <fantasai> dbaron: Suggesting font-size-adjust: auto to mean, use the x-height of the user's default font
1042. # [23:36] <fantasai> jdaggett: the tricky part is that the default font isn't always one font
1043. # [23:36] <fantasai> dbaron: I would love to get this weird font pref setting thing
1044. # [23:37] <fantasai> dbaron: It might require a little bit more, but that bit can be browser-specific
1045. # [23:37] <TabAtkins> s/get this/get rid of this/
1046. # [23:37] <fantasai> dbaron: I would also like to allow authors to opt-into this world of consistent x-heights
1047. # [23:37] <fantasai> dbaron: by aligning to a reasonable defautl font
1048. # [23:37] <fantasai> dbaron: Authors can do something similar by font-size-adjust: 0.5
1049. # [23:38] <fantasai> dbaron: But that changes the user's default size, even if they don't want to, by the amount by which that factor is off
1050. # [23:38] <TabAtkins> szilles: I'm confused about what the "user's default font-size" is.
1051. # [23:38] <fantasai> dbaron: There's the issue that the default font size does vary by language
1052. # [23:39] <fantasai> dbaron: Some browsers have lang-specific font preferences
1053. # [23:39] <fantasai> dbaron: so we might use those
1054. # [23:39] <fantasai> szilles: If i set a font ...
1055. # [23:39] * anne ... cookies!
1056. # [23:39] <fantasai> dbaron: If you set a font, not use the user's default, you are likely to keep more closely to the effective font size of the user's default
1057. # [23:41] <fantasai> dbaron: font-size-adjust: auto only depends on the default font-family, not on the default font-size
1058. # [23:42] <ChrisL> useful discussion at http://www.emdpi.com/css3xheight.html
1059. # [23:42] <fantasai> szilles: So.. 'auto' makes a bunch of assumptions about where to go look for things
1060. # [23:42] <fantasai> szilles: And those assumptions work in pages where people use the default font
1061. # [23:42] * Quits: mjs (mjs@17.203.15.150) (Connection reset by peer)
1062. # [23:42] <fantasai> szilles: Seems it wouldn't work as well to change the default font
1063. # [23:43] <fantasai> dbaron: If they change the font, then they can also set a different font-size-adjust
1064. # [23:43] <fantasai> szilles: But the values are hard to figure out
1065. # [23:43] <fantasai> szilles: It would make more sense to say "match my parent's ex-height"
1066. # [23:44] <ChrisL> elika: no, we are just refining thr typographical color (priceless!!)
1067. # [23:44] <fantasai> fantasai: That's an interesting idea. Setting it on the root would hit up the initial font
1068. # [23:45] <fantasai> howcome: Are we proposing to change page layouts across the web?
1069. # [23:45] <fantasai> ...
1070. # [23:45] * Quits: cslye (cslye@17.244.3.65) (Quit: cslye)
1071. # [23:45] <fantasai> Bert, howcome: maybe be more useful as we see more fonts used
1072. # [23:46] <fantasai> Alex: We have gotten requests for font-size-adjust
1073. # [23:47] <fantasai> dbaron: font-size-adjust was in CSS2.10
1074. # [23:47] <fantasai> er
1075. # [23:47] <fantasai> CSS2.0
1076. # [23:47] <fantasai> jdaggett: I think it's a somewhat cumbersome feature
1077. # [23:48] <fantasai> jdaggett: But I see people saying "I want this!" and when I see what they describe, it's font-size-adjust
1078. # [23:48] <fantasai> dbaron: It's implemented in Gecko
1079. # [23:48] <fantasai> Alex: I'm not going to confirm or deny the plans for IE9
1080. # [23:48] <fantasai> ChrisL: I think the proposal has merit
1081. # [23:49] <fantasai> jdaggett: To me the big problem here is what you're calling the default font
1082. # [23:49] <fantasai> jdaggett: Because that's something that's not defined normatively
1083. # [23:49] <fantasai> jdaggett: ANd it's important for having this feature work consistently
1084. # [23:49] <fantasai> dbaron: I Tried to leave a bit of latitude for determining what exactly the default font is
1085. # [23:50] <fantasai> howcome: I think I like Steve's proposal to use the root element
1086. # [23:50] <fantasai> dbaron: I don't quite understand how that proposal would work.
1087. # [23:51] <ChrisL> a font example with a fairly small x-height http://www.fonts.com/FindFonts/detail.htm?pid=203205#waterfall
1088. # [23:51] <fantasai> Steve: The value on the root element, unless one is specified, is going to be the default.
1089. # [23:51] <fantasai> Steve: I can explicitly set a value on the root element
1090. # [23:51] <fantasai> Steve: And have that used instead of the default font
1091. # [23:51] <fantasai> Steve: So that could be the default font, but it doesn't have to be
1092. # [23:52] <fantasai> dbaron explains something about overriding
1093. # [23:52] <fantasai> dbaron: let's distinguish between user's default font-family and size
1094. # [23:52] <fantasai> dbaron: This proposal gives a better way of matching the default font *size*
1095. # [23:53] <fantasai> dbaron: It also gives users a better way to deal with the monospace-proportional harmonization problem
1096. # [23:53] <fantasai> Steve: That case is handled either way
1097. # [23:54] <fantasai> dbaron: example
1098. # [23:54] <fantasai> dbaron: Suppose the author wants to preserve the user's size
1099. # [23:54] <fantasai> dbaron: But wants to use verdana
1100. # [23:54] <fantasai> dbaron: They'd need this feature to effectively preserve the size
1101. # [23:54] <fantasai> dbaron: because actually preserving the size, without this adjustment, would result in a much bigger-looking font
1102. # [23:55] <fantasai> howcome: initial value?
1103. # [23:55] <fantasai> dbaron: initial value is none
1104. # [23:55] <fantasai> dbaron: If we wanted to replace the current monospace hackery
1105. # [23:56] <fantasai> dbaron: We would have to make the initial value be a value that if an element or one of its ancestors had a font size in absolute units, this special value would behave like none
1106. # [23:56] <fantasai> dbaron: and otherwise the special value would be have like auto
1107. # [23:56] <fantasai> dbaron: at least, in the way Gecko implement monospace pref
1108. # [23:56] <fantasai> Steve: I'm confused why you think the default font size has anything to do with what I'm looking
1109. # [23:57] <fantasai> fantasai: So there are three use cases here, and dbaron's solves one, steve's solves another, and both solve the third
1110. # [23:58] <glazou> jdaggett, we'll brak for 15 minutes in 5 minutes from now, ok for you?
1111. # [23:58] <glazou> s/brak/break
1112. # [23:58] <fantasai> 1. Match the user's default size as well as possible, meaning ex-height matching
1113. # [23:59] <jdaggett> glazou: yeah, i have to leave soon
1114. # [23:59] <glazou> ok
1115. # [23:59] <jdaggett> time to make breakfast
1116. # [23:59] <glazou> eheh
1117. # [23:59] <fantasai> 2. Consistent ex-heights across font-switching throughout the document, esp. mononspace vs. proportional
1118. # [23:59] * Bert thinks more about afternoon tea than breakfast :-)
1119. # [23:59] <fantasai> stevez: The third use case is to match the ex-heights locally
1120. # Session Close: Wed Mar 31 00:00:00 2010

The end :)