/irc-logs / w3c / #css / 2011-10-31 / end

Options:

1. # Session Start: Mon Oct 31 00:00:00 2011
2. # Session Ident: #css
3. # [00:01] <fantasai> howcome explains his use case in more detail
4. # [00:02] <fantasai> howcome: You have the gr unit, yes.
5. # [00:02] <fantasai> Steve: There's a separation between the positioning model and the ability to exclude
6. # [00:03] <fantasai> Tantek and howcome discuss the issue, howcome says you can do this with gcpm
7. # [00:03] * Quits: Ms2ger (Ms2ger@91.181.84.233) (Quit: nn)
8. # [00:03] <fantasai> Rossen: That solves horizontal position, but not vertical
9. # [00:04] * tantek was wondering if/how you can set a float to have a margin-right of -50% of its width
10. # [00:04] <tantek> and Håkon claims GCPM has the ability to do this.
11. # [00:04] <fantasai> Rossen: If you can do something with abspos today, you can exclude it
12. # [00:04] <fantasai> vhardy: We're not talking about positioning, just the exclusions aprt
13. # [00:04] <fantasai> s/aprt/part/
14. # [00:04] <fantasai> howcome: We have an opportunity to make floats better
15. # [00:04] <fantasai> Tantek: floats are so fragile, we shouldn't touch them
16. # [00:04] * Joins: pudgetta (50ba57d0@207.192.75.252)
17. # [00:05] <fantasai> howcome: We need floats to the top/bottom of the colu,n
18. # [00:05] <fantasai> Rossen: You could have 'float' value to top/bottom/left/right
19. # [00:05] <fantasai> Rossen: But that's orthogonal to what we're doing here
20. # [00:05] * Quits: pudgetta (50ba57d0@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
21. # [00:06] <fantasai> howcome: This case is the most common case for pull-quotes in newspapers
22. # [00:06] <fantasai> ...
23. # [00:06] <fantasai> Tantek: I'm willing to accept that examples exist, but I want documentation that they're common
24. # [00:07] * Joins: plinss (plinss@64.129.229.106)
25. # [00:07] <fantasai> Steve: I can provide examples in multiple scripts
26. # [00:08] <fantasai> howcome: go to wikipedia and search for pull-quote
27. # [00:08] <ChrisL> http://en.wikipedia.org/wiki/Pull_quote
28. # [00:08] <fantasai> Alan: This spec is about, not where the pull quote is, but how things wrap aorundit
29. # [00:08] <ChrisL> http://en.wikipedia.org/wiki/File:Pull-Quote.PNG
30. # [00:08] <fantasai> Tantek: My experience is that pull-quotes are positioned relative to the page, not the columns
31. # [00:09] <fantasai> dbaron: Does somebody have the Sunday NYT?
32. # [00:09] <fantasai> howcome: You can do this already
33. # [00:09] * Joins: szilles (chatzilla@192.150.10.201)
34. # [00:10] <bradk_> http://blog.psprint.com/wp-content/uploads/2009/01/pull-quote.jpg
35. # [00:10] <fantasai> ...
36. # [00:10] <fantasai> vhardy: Positioning is in a separate module. We're not trying to improve positioning at all.
37. # [00:11] <tantek> nice example bradk
38. # [00:11] <fantasai> dbaron: I'm suspicious of the claim that we should think about positioning separately because the whole multi-pass layout issue is very tied into the positionng model we're using
39. # [00:11] <fantasai> dbaron: Using a 2-pass approach will have different amounts of approximaion error. In some models it'll be close, in others your content will be somewhere completely unrelated.
40. # [00:12] <fantasai> Rossen: We had this note about 2-pass implementation. Almost all of the concerns I saw on the mailing list was about scaling this for interactive media
41. # [00:12] <stearns> the wikipedia pull quote example is incredibly ugly
42. # [00:12] <fantasai> Rossen: Based on that, Dave Hyatt and you were asking how do we make this not exponential ...
43. # [00:12] <fantasai> Rossen: because abspos elements' positions, once they're exclusions, can be affected by themselves.
44. # [00:13] <fantasai> Rossen: We're proposing this approximation to solve the exponential problem.
45. # [00:13] <fantasai> Rossen: Can it be improved, sure. Would like to keep running times fairly linear and keep approximation better.
46. # [00:13] <tantek> does "how do we make this not exponential…" mean "how do we make this not max out the CPU and fans on our laptops" ?
47. # [00:13] <fantasai> dbaron: I agree that we shouldn't have an exponential performance problem. But I'd rather solve that by coming up with a system that doesn't need it than by coming up with the wrong results.
48. # [00:14] <fantasai> dbaron: ... If people want to z-index things, they'll use relpos ...
49. # [00:14] <fantasai> dbaron: If you use exclusions with in-flow things, you'll still end up off.
50. # [00:14] <fantasai> ...
51. # [00:15] * Quits: Liam (liam@128.30.52.169) (Ping timeout)
52. # [00:15] <fantasai> Alex: Better algorithm is known to exist, but isn't used due to perf.
53. # [00:15] <fantasai> Alex: For exmaple if you do layout for floats, you can have O(n) or more than that.
54. # [00:15] <fantasai> Alex: I'm still worried about it.
55. # [00:16] <fantasai> vhardy: Maybe best way is to publish WD and collect issues
56. # [00:16] <fantasai> vhardy: There were 3 proposals that were considered, we went over them in Seattle, and this is the result of consolidating
57. # [00:16] <fantasai> vhardy: Our request is to publish as WD so we can have comments and iterate on it
58. # [00:16] <fantasai> vhardy: People say its hard or complicated, put it to the test by implementing.
59. # [00:17] <fantasai> dbaron: Basically once we decide to publish something as a WD, it keeps moving whether we like it or not. So to some extent, that's the point we decide whether this a model that we want.
60. # [00:17] <fantasai> dbaron: And I'm not at all convinced that this is a model that we want.
61. # [00:17] <fantasai> Steve: What exactly are you not convinced about?
62. # [00:17] <fantasai> dbaron: Largely the tie-in to the abpos model
63. # [00:18] <fantasai> Molly: Is that a preference for a float model, or not specific?
64. # [00:18] <fantasai> Rossen: What's the alternative?
65. # [00:18] <fantasai> Alex: Would you prefer this kind of exclusions to only apply a new kind of floats and define that to have a better behavior?
66. # [00:19] <fantasai> dbaron: I would like to see some of this stuff work in terms of new types of floats, like what howcome's done with page floats.
67. # [00:19] <fantasai> Alex: this doesn't do anything about float collisions, they overlap
68. # [00:19] <fantasai> Alex: There are issues with error accumulation
69. # [00:19] <fantasai> Alex: I think both are really almost out of scope of the exclusions spec. they define what happens with shapes
70. # [00:19] <fantasai> Alex: If we define new kind of layout, still have to figure out these problems of overlap and positioning backwards.
71. # [00:20] <fantasai> Alex: There are problems in the spec. If the things exclusions apply to, if they were not anything including abspos. If they only applied e.g. to page floats, it would still have these problems, right?
72. # [00:20] <fantasai> dbaron: Not exactly, because the page float model still has places in document order I believe
73. # [00:20] <fantasai> Alex: can you have them overlap?
74. # [00:21] <fantasai> howcome: Only if you do negative margins. By nature they avoid each other
75. # [00:21] <fantasai> Rossen: Would they affect each others' wrapping?
76. # [00:21] <fantasai> howcome: no
77. # [00:21] <fantasai> Bert: All the examples of exclusions seem to be doable with shapes
78. # [00:21] <fantasai> Bert: maybe you only need shapes
79. # [00:22] <fantasai> vhardy: ...
80. # [00:22] <fantasai> Bert: assume this is one <p> element with 2 columns. THe shape is a donut shape, but it's still the shape of the <p> itself. don't need any other elements for it
81. # [00:22] <fantasai> Bert: Advantage of that is you don't need to invent some pseudo-element to create that circle.
82. # [00:23] <fantasai> Bert: oh, you're using an empty element. Oh that is a no-no. Don't create elements just to create shapes.
83. # [00:23] <fantasai> several: It's just an example
84. # [00:24] <fantasai> Bert: In the next example, you don't need exclusions, you just need three shapes
85. # [00:24] <fantasai> Rossen: What you're suggesting was also suggested by glazou. He suggested using bg image as exclusion.
86. # [00:24] <fantasai> Arno: Works for static layout only
87. # [00:25] <fantasai> dbaron: I don't think this works for interactive media either.
88. # [00:25] <fantasai> Bert: The circle there is not expanding.
89. # [00:25] <fantasai> Rossen: It's percent sized
90. # [00:25] <fantasai> Tantek: In terms of content.
91. # [00:26] <fantasai> fantasai: So I see several concerns here.
92. # [00:26] <fantasai> fantasai: One is error accumulation vs. performance
93. # [00:26] <TabAtkins_> scribenick: TabAtkins_
94. # [00:26] <TabAtkins_> fantasai: Another one is the actual fluidity of the layout with respect to different amts of content, different font sizes, page sizes, etc.
95. # [00:27] <TabAtkins_> fantasai: I see a lot fo example here that have fixed sizes, that wouldn't work well if you increased the font size.
96. # [00:27] <TabAtkins_> arno: That's just an example with the examples, though, right?
97. # [00:27] <TabAtkins_> fantasai: Not necessarily. A circle would have an explicit size in real content. You may need a shrink-to-fit circle.
98. # [00:28] <TabAtkins_> fantasai: To see that the spec authors aren't considering this kind of concerns me, because you have to make sure that dynamic unpredictable content is handled.
99. # [00:28] <TabAtkins_> Rossen: We're not doing anything to prevent shrink-to-fit. Any abspos will, by default, be shrink-to-fit.
100. # [00:28] <TabAtkins_> Rossen: So making it an exclusion won't change that.
101. # [00:28] <TabAtkins_> Rossen: What you may be actually concerned about is a problem with *shapes*, not exclusions.
102. # [00:29] <fantasai> fantasai^: because that's the kind of environment we operate in
103. # [00:29] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
104. # [00:30] <TabAtkins_> Topic: CSS Shapes
105. # [00:30] <TabAtkins_> Rossen: Shapes are a way to define geometry for exclusions (how stuff outside the element wraps around it) or the inside (how contents are wrapped inside of it).
106. # [00:31] <fantasai> Note, shouldn't the term "flow container" be "block container" per 2.1?
107. # [00:31] <TabAtkins_> Rossen: We are proposing 2 ways to define the shape itself.
108. # [00:31] <TabAtkins_> Rossen: An SVG-like syntax, with functions matching the SVG geom primitives.
109. # [00:31] <TabAtkins_> Rossen: And a way to reference an image (raster or SVG) that defines the shape automatically.
110. # [00:32] <TabAtkins_> Rossen: The idea here is that wrapping around elements becomes quickly boring if done solely around rectangles.
111. # [00:32] <ChrisL> Chris: can it point to path in that case
112. # [00:32] <ChrisL> Rossen: yes
113. # [00:32] <TabAtkins_> Rossen: So for that, we're introducing 'shape-outside', which can be applied to exclusions.
114. # [00:32] <TabAtkins_> Rossen: Initial value is 'auto', which computes to the box of the element.
115. # [00:33] * tantek is very happy to finally see CSS Shapes formally proposed.
116. # [00:33] <TabAtkins_> Rossen: 'shape-inside' has the same values plus one, ''outside-shape'', which refers to the outer shape.
117. # [00:33] * Quits: BradK (bradk@64.129.229.106) (Quit: Buh bye)
118. # [00:33] * tantek refers to circa 2001 example: http://tantek.com/CSS/Examples/shapes.html
119. # [00:33] * Joins: shepazu (shepazu@128.30.52.169)
120. # [00:33] <TabAtkins_> Rossen: By default, we want content that is nicely wrapped around as a circle to also wrap its contents as a circle.
121. # [00:33] <tantek> developed soon after / based on: http://tantek.com/CSS/Examples/polygons.html
122. # [00:33] <TabAtkins_> Rossen: You can do that, or define an entirely new shape.
123. # [00:34] <TabAtkins_> Rossen: -inside and -outside are coupled by default, but you can give different values if you want.
124. # [00:34] <TabAtkins_> jdaggett_: With 'shape-inside', if you have a donut, does text flow around the hole?
125. # [00:35] * fantasai supposes we'll need 'outside-shape' and 'inside-shape' keywords for 'background-clip', too
126. # [00:35] <TabAtkins_> fantasai: The 'outside shape' represents the border box/margin box.
127. # [00:36] <TabAtkins_> fantasai: Shape-inside shapes the content box.
128. # [00:36] <fantasai> fantasai^: outside shape shapes the impact of the element on surrounding content
129. # [00:36] <fantasai> fantasai^: inside shape affects the containing block shape for the content of the element
130. # [00:36] <TabAtkins_> Rossen: [shows an example from the spec with "C" shapes and content flowing into the "space".
131. # [00:37] <TabAtkins_> vhardy: [explains the example in more detail]
132. # [00:38] * Joins: gamakichi (56b297f6@64.62.228.82)
133. # [00:39] * Parts: gamakichi (56b297f6@64.62.228.82)
134. # [00:39] <TabAtkins_> Rossen: The contents of an element with a donut shape fill in the entire area of the shape.
135. # [00:40] <TabAtkins_> jdaggett_: I'd like to use this with a type shape, like having a giant A with text flowing around and through the holes.
136. # [00:40] <TabAtkins_> Rossen: Yes, that can be done if you extract the shape.
137. # [00:40] <TabAtkins_> jdaggett_: It would be nice to have text as a built-in shape.
138. # [00:40] <TabAtkins_> Bert: Q about shape-outside.
139. # [00:41] <dbaron> q+ to ask about commas
140. # [00:41] <TabAtkins_> Bert: Some time ago we came up with the case that the shape to wrap around is an image.
141. # [00:42] <TabAtkins_> Bert: So it looks like you'd have to repeat the url of the image both in <img> and in 'shape-outside'. We previously had a value called 'contour' that would automatically grab the image when specified on an image.
142. # [00:43] <ChrisL> If you point to a raster image, does it threashold the alpha map to get the image shape?
143. # [00:43] <TabAtkins_> <img id=shape-me url=foo><style>#shape-me { shape-outside: contour; }</style> //equal to 'shape-outside: url(foo)'
144. # [00:44] <ChrisL> Vincent: Yes there is a threashold
145. # [00:44] <fantasai> ACTION: Make attr() function do the right thing wrt resolving relative URLs
146. # [00:44] * trackbot noticed an ACTION. Trying to create it.
147. # [00:44] * RRSAgent records action 6
148. # [00:44] <trackbot> Sorry, couldn't find user - Make
149. # [00:45] <fantasai> ACTION fantasai: Make attr() function do the right thing wrt resolving relative URLs
150. # [00:45] * trackbot noticed an ACTION. Trying to create it.
151. # [00:45] * RRSAgent records action 7
152. # [00:45] <trackbot> Created ACTION-383 - Make attr() function do the right thing wrt resolving relative URLs [on Elika Etemad - due 2011-11-06].
153. # [00:45] <TabAtkins_> So that would be shape-outside: attr(src as url);
154. # [00:45] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
155. # [00:46] <TabAtkins_> bradk_: Another feature request - have a keyword to grab the background image, rather than repeating yourself.
156. # [00:46] <TabAtkins_> Bert: What about if there are multiple background images?
157. # [00:46] <TabAtkins_> Rossen: Daniel brought that up in the last f2f - there were a lot of limitations.
158. # [00:47] <TabAtkins_> dbaron: In CSS2 there was a property called 'clip', where the examples had commas and the formal syntax didn't. We resolved that by allowing both.
159. # [00:47] <TabAtkins_> dbaron: This spec has the same problem, but the other way around.
160. # [00:47] * Joins: szilles (chatzilla@192.150.10.201)
161. # [00:48] <TabAtkins_> TabAtkins_: I'd prefer to match SVG and make commas optional.
162. # [00:49] <TabAtkins_> Rossen: Our preference now is to move forward on a WD.
163. # [00:49] <TabAtkins_> howcome: What if we throw out shapes and only do images?
164. # [00:50] <fantasai> Tab: I'll note the spec is silent on what to do for animated GIFs
165. # [00:51] <TabAtkins_> Rossen: We looked at a lot of examples in print media, where wrapping around images was used a lot.
166. # [00:51] <TabAtkins_> Rossen: Like SI with lots of athletes with text around them.
167. # [00:51] <TabAtkins_> Rossen: But with shapes, it makes it nice to have a really simple way to do this.
168. # [00:51] <TabAtkins_> ChrisL: Agreed.
169. # [00:52] <TabAtkins_> Rossen: Maybe we could reduce the set of types to circle, maybe polygon?
170. # [00:53] <TabAtkins_> TabAtkins_: While hakon was joking about animated gifs, I'm not. That needs to be defined. Maybe first frame?
171. # [00:53] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
172. # [00:54] <TabAtkins_> jdaggett_: What about animating shapes in Transitions?
173. # [00:54] <TabAtkins_> TabAtkins_: SVG knows how to animate shapes, so we can do that.
174. # [00:54] <TabAtkins_> ChrisL: I'd like to see this pushed out for wider review at this point.
175. # [00:55] <TabAtkins_> dbaron: I'm scared that what's happened lately is that pushing something to TR means we're calling for implementations.
176. # [00:56] <fantasai> TabAtkins_: Could we address dbaron's concern by adding a scary notice?
177. # [00:56] <fantasai> glazou: It's a Working Draft. It's already a *Draft*.
178. # [00:57] <fantasai> glazou: Proposal is to publish FPWD provided the issues list is updated
179. # [00:57] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
180. # [00:57] <fantasai> RESOLVED: Publish FPWD of Exclusions
181. # [00:58] <fantasai> Topic: Style Attributes
182. # [00:58] <fantasai> Arron: I didn't finish the implementation report yet, but I ran all the tests, all three of them.
183. # [00:58] <fantasai> Arron: There needs to be three other tests, but all browsers pass except one case which is passed by 2
184. # [00:58] * Joins: JohnJansen (qw3birc@128.30.52.28)
185. # [00:59] <fantasai> dbaron: Is there a test for rejecting if there are braces around it?
186. # [00:59] * Joins: szilles (chatzilla@192.150.10.201)
187. # [00:59] <fantasai> fantasai: yes.
188. # [00:59] <fantasai> Arron: I'll try to finish off tonight.
189. # [01:00] <fantasai> ACTION Arron: finish implementation report and tests
190. # [01:00] * trackbot noticed an ACTION. Trying to create it.
191. # [01:00] * RRSAgent records action 8
192. # [01:00] <trackbot> Created ACTION-384 - Finish implementation report and tests [on Arron Eicholz - due 2011-11-06].
193. # [01:00] <fantasai> ACTION fantasai: Publish test suite and implementation report on w3.org
194. # [01:00] * trackbot noticed an ACTION. Trying to create it.
195. # [01:00] * RRSAgent records action 9
196. # [01:00] <trackbot> Created ACTION-385 - Publish test suite and implementation report on w3.org [on Elika Etemad - due 2011-11-06].
197. # [01:00] <fantasai> Topic: Selectors 4
198. # [01:00] <fantasai> glazou: Selectors L4 triggered a major reaction from web designer community because of subject selector and :matches()
199. # [01:01] <fantasai> glazou: I can see that people don't really understand that presence of a feature in a WD doesn't mean it will be in an implementation
200. # [01:01] <fantasai> glazou: I would like us to, at least for :matches() and subject selector, to clean up things asap
201. # [01:02] <fantasai> glazou: If it's not going to be implemented by browser vendors because it doesn't fit into your strategy or impl architecture,
202. # [01:02] <fantasai> glazou: then remove it from the spec quickly
203. # [01:03] <fantasai> fantasai: :matches() is already implemented
204. # [01:03] <TabAtkins_> glazou: My fear is just that if we have something nice on paper that we find is too expensive to code, we should remove it quickly.
205. # [01:04] <TabAtkins_> fantasai: I think trying to cut off brainstorming work because people will interpret it wrong is bad.
206. # [01:04] <fantasai> fantasai: the subject indicator may wind up in batch processors
207. # [01:04] <TabAtkins_> glazou: I'm not saying that, just that if our brainstorming finds something isn't implementable we should remove it as quickly as possible.
208. # [01:04] <fantasai> fantasai: could be done in browsers, but will require careful optimization work
209. # [01:05] <fantasai> fantasai: so may take awhile to find out
210. # [01:05] <TabAtkins_> arno: Do we know if anyone's currently planning to implement it?
211. # [01:05] <TabAtkins_> fantasai: There are tons of features - it's a very early stage draft - so we don't know that yet.
212. # [01:05] <TabAtkins_> glazou: I just didn't expect such a massively positive reaction to it as we got.
213. # [01:06] <TabAtkins_> szilles: So this falls into "careful what you promise, they might ask for it".
214. # [01:07] <TabAtkins_> glazou: So I'm specifically asking for devs to evaluate implementability as soon as possible on that feature.
215. # [01:07] <TabAtkins_> fantasai: What's in :matches() is absolutely implementable, since it's just syntactic sugar.
216. # [01:07] <TabAtkins_> fantasai: So we don't need feedback on that.
217. # [01:07] <TabAtkins_> fantasai: (At least, not immediately.)
218. # [01:08] * Joins: BradK (bradk@64.129.229.106)
219. # [01:08] <TabAtkins_> fantasai: It's the subject indicator that needs feedback.
220. # [01:08] * Bert to fantasai: typo in selectors4: ':dir' and ':any-link' are not marked as level 4.
221. # [01:08] <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=418039 is the Mozilla bug on :subject
222. # [01:08] <TabAtkins_> tantek: What about :has()?
223. # [01:08] <arno> indicator -> selector
224. # [01:08] <TabAtkins_> tantek: It's in jQuery, it's been adopted and liked.
225. # [01:09] <TabAtkins_> fantasai: I specifically went away from that because it's harder to ipmlement.
226. # [01:10] <TabAtkins_> TabAtkins_: Simple useful example: "label:has(:checked) + p"
227. # [01:10] <TabAtkins_> fantasai: You can use :matches() and the subject indicator to do the same.
228. # [01:11] <Bert> (Tab's example doesn't work, does it? The p is not a sibling of the label, but a sibling of the labels's parent.)
229. # [01:13] <TabAtkins_> fantasai: "label:matches(? > :checked) + p"
230. # [01:13] * Joins: kermit (ae14bf07@78.129.202.38)
231. # [01:13] <TabAtkins_> fantasai: [explains her example further]
232. # [01:13] <dbaron> Clearly we should just use the ‽ operator or the ¡ or ¿ operator.
233. # [01:14] <tcelik> please no more symbols with strange meanings
234. # [01:14] * tcelik prefers to avoid CSS hieroglyphics
235. # [01:14] * hober CSS IS *&@%#&*%^ AWESOME!
236. # [01:14] <dbaron> ok, how about the 美 symbol :-)
237. # [01:15] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
238. # [01:16] <TabAtkins_> dbaron: The spec should say that using the subject indicator twice in a selector makes it invalid.
239. # [01:18] <TabAtkins_> tantek: I still think :has() is a superior syntax. If you want to put restrictions on its functionality to match the subject indicator, fine, but use the better syntax.
240. # [01:18] <dbaron> Let's avoid Dr. Streetmentioner's 1001 Tenses for Time Travelers
241. # [01:18] * Joins: szilles (chatzilla@192.150.10.201)
242. # [01:19] <TabAtkins_> fantasai: The interesting cases that :has() allows are precisely those that are much harder to implement.
243. # [01:19] <TabAtkins_> fantasai: Selectors *never* go down multiple branches when matching, right now.
244. # [01:19] <TabAtkins_> fantasai: Tab's example requires going down one branch and then going down another.
245. # [01:20] <TabAtkins_> Bert: The XPath syntax may be eaiser here, where it has an explicit ancestor selectors.
246. # [01:20] <TabAtkins_> dbaron: It's less hard to implement, than that it's hard to track dynamic changes.
247. # [01:21] <TabAtkins_> dbaron: For example, if you're selecting (in Tab's example), when the input is checked or not, you need to quickly figure out which elements need to be restyled, without redoing the entire page's layout.
248. # [01:22] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
249. # [01:22] <TabAtkins_> RESOLVED: Publish Style Attribute PR as soon as we have the impl reports.
250. # [01:23] * Joins: anne (annevk@209.119.68.98)
251. # [01:28] <TabAtkins_> Topic: GCPM
252. # [01:28] <TabAtkins_> howcome: I'd like to talk about what's new.
253. # [01:28] * Quits: kermit (ae14bf07@78.129.202.38) (Quit: http://www.mibbit.com ajax IRC Client)
254. # [01:28] <TabAtkins_> howcome: Most of this is based on page flaots, but also paged overflow.
255. # [01:28] <TabAtkins_> howcome: You can tell an element to overflow into pages.
256. # [01:28] <TabAtkins_> tantek: So it's a manual <marquee>?
257. # [01:29] <TabAtkins_> howcome: The other thing from GCPM is page floats. These photos [in his slides] are floats spanning multiple columns.
258. # [01:29] <TabAtkins_> howcome: It works even better on a tablet.
259. # [01:30] <TabAtkins_> howcome: So basically we can create an e-reader.
260. # [01:30] <TabAtkins_> howcome: Paged layouts have been used forever in real life. Also in lots of apps, like flipboard.
261. # [01:30] <TabAtkins_> howcome: [shows an example of paged wikipedia]
262. # [01:31] <TabAtkins_> howcome: It has a lot of nice properties.
263. # [01:31] * Quits: drublic (drublic@95.115.25.171) (Client exited)
264. # [01:31] <TabAtkins_> howcome: It avoids cut lines on the top and bottom of the screen when scrolling, frex.
265. # [01:31] <TabAtkins_> howcome: Some things were *designed* for paged presentations, like children's book.
266. # [01:32] <TabAtkins_> howcome: There's tons of gutenberg text, for example, that nobody will read because it's not paged.
267. # [01:32] <TabAtkins_> [shepazu objects]
268. # [01:32] <TabAtkins_> howcome: We've ipmlemented it in Opera, and have a shadow DOM for it.
269. # [01:33] <TabAtkins_> s/shadow DOM/OM/
270. # [01:33] <TabAtkins_> howcome: [shows example of some presentation showing the current page, etc.]
271. # [01:33] <TabAtkins_> howcome: It's very simple. The basic setup is with a 'paged' value for overflow, and the nav is done through an at-rule.
272. # [01:33] <TabAtkins_> plinss: How does it print?
273. # [01:34] <TabAtkins_> howcome: Quite well. Opera doesn't print well, but if you pipe it to a good printing tool, it works well.
274. # [01:35] <TabAtkins_> plinss: When you're doing pagination of an element in the page, what happens when you print the whole page? Where's the overflow?
275. # [01:35] <TabAtkins_> howcome: [shows the code example to set it up]
276. # [01:35] <TabAtkins_> fantasai: Since the overflow property on <html> is propagated to the viewport, you don't need the height:100% there.
277. # [01:36] <TabAtkins_> fantasai: Last time, we were thinking of having 'paged' be a value for overflow-style.
278. # [01:36] <TabAtkins_> howcome: Yes, 'overflow' is a shorthand. The value can go anywhere, it doesn't matter right now.
279. # [01:36] <TabAtkins_> howcome: You can distinguish between pages being side-by-side, or below each other.
280. # [01:37] <TabAtkins_> tantek: In Japanese, you get pages right to left.
281. # [01:37] <TabAtkins_> fantasai: So you also have to check writing-mode, not just direction.
282. # [01:37] <TabAtkins_> howcome: Right. If I say "paged-x", I take whichever logical direction is horizontal.
283. # [01:38] <TabAtkins_> shepazu: The scrollbar gives nice discoverability of how much content is left. Is that still there?
284. # [01:38] <TabAtkins_> shepazu: Could there be a property that adds an indicator of the expected flow left?
285. # [01:38] <TabAtkins_> shepazu: "If there's another page, put an indicator there"
286. # [01:38] <TabAtkins_> plinss: There's an example in the spec with "paged-x-controls" for that, I guess.
287. # [01:39] <TabAtkins_> glazou: How does this interact with @page rules?
288. # [01:39] <TabAtkins_> howcome: Right now, our impl doesn't pay attention. In the future, if you set the viewport to be overflow:scroll, it'll interact.
289. # [01:40] <TabAtkins_> howcome: If a line runs over the page (in the direction perpendicular from the main scrolling direction), it just gets cut (you can't see it in any way).
290. # [01:40] <TabAtkins_> howcome: Same as with multicol.
291. # [01:40] <fantasai> Tab: These us multicol, so you have columns: 3 or whatever.
292. # [01:40] <fantasai> Tab: If you're using columns, the overflow columns are to the side.
293. # [01:41] * Quits: dino (dino@63.145.238.4) (Quit: dino)
294. # [01:41] <fantasai> fantasai: The columns are not overflowing the box. They're overflowing the page, and go to the next page. It just happens that the next page is physically placed to the side rather than below in this case.
295. # [01:42] <fantasai> howcome: you see this in tablet apps, that do this repeatedly
296. # [01:42] <fantasai> howcome: This is a very simple sketch.
297. # [01:43] <fantasai> howcome shows page shift effects
298. # [01:43] <fantasai> Brad: I think that should be up to the UA, so the UA can provide a consistent interface
299. # [01:43] <fantasai> glazou: I don't see it as only for tablets. It's a wonderful spec to match the effects of switching slides in a powerpoint
300. # [01:43] <fantasai> glazou: I think the primary usage of that will be slideshows, much more than tablet browsing
301. # [01:44] <fantasai> molly: possibly, but I can see designers really loving it
302. # [01:44] <fantasai> glazou: You can define navigation between 2 pages in same document, or between 2 documents.
303. # [01:44] <fantasai> glazou: One issue we have with slideshows to dissolve one slide and show the next slide; we don't have the next slide yet when we load the document.
304. # [01:44] <fantasai> molly: I want to make the case for this and not just slide shows.
305. # [01:45] <fantasai> molly: Anyone read the NYT? Exactly what people are doing in NYT reader
306. # [01:45] * Joins: myakura (myakura@209.119.68.98)
307. # [01:45] <fantasai> molly: it's being adopted a lot esp by older users who are not computer-savvy
308. # [01:45] <fantasai> howcome: Met with NYT last week, who are doing all this in JS. They are saying please save us from the javaScript
309. # [01:46] <fantasai> howcome: I'm really euphoric about this. I think it's the best thing that's happened in a long time.
310. # [01:46] <fantasai> sylvaing: Since the Romans!
311. # [01:46] <fantasai> howcome: It's so simple. No new properties, just new values on existing properties
312. # [01:46] <fantasai> howcome: And then it's the at-page tihng, which attaches to link elements in HTML
313. # [01:47] <fantasai> howcome: here we tie thse relationships to the directions with an at-rule
314. # [01:47] <fantasai> howcome shows example of @navigation using link-rel() notation
315. # [01:47] <fantasai> howcome: If we want to compete with the apps here, I think we need to provide this form of interaction
316. # [01:47] <fantasai> plinss: I think it's great on the root element
317. # [01:47] <fantasai> plinss: When its on the child element, and you turn the page, what happens?
318. # [01:47] <fantasai> howcome: Here it's on the child element
319. # [01:48] <fantasai> plinss: Now hit print.
320. # [01:48] <fantasai> howcome: I see your point.
321. # [01:48] <fantasai> fantasai: I think you should print the page over again with the next child page until you run out of content in the child
322. # [01:49] <fantasai> fantasai: Would solve lots of problems with fixed positioning
323. # [01:49] <fantasai> fantasai: Although it would be weird if you had more than one paged child
324. # [01:50] <fantasai> Tantek: Shouldn't print starting at what you're looking at, should print the entire document.
325. # [01:50] <fantasai> Tantek: Wrt slideshows, it's horrible because then you don't get anchors to the slides
326. # [01:50] <fantasai> tantek: If you do it with anchors tags, HTML5 history, fine. I've built that.
327. # [01:50] <fantasai> Tantek: But you can't do dynamic paging with anchors
328. # [01:51] <fantasai> plinss: It's the same problem of scrolling down to a page and wanting to point someone at that point.
329. # [01:51] <fantasai> Tantek: yes, but the expectation is different: if I'm on a page, I expect to send a link to the page. If I'm in a scrolling document, I expect a link to that page to point at the top
330. # [01:52] <fantasai> ...
331. # [01:52] <fantasai> howcome: If I'm at the end of the document, it goes to the next one
332. # [01:52] <fantasai> Doug: How do you know what's the next document?
333. # [01:52] <fantasai> howcome: with HTML <link> tags
334. # [01:52] <fantasai> howcome: you tie them to the navigation like this
335. # [01:53] <fantasai> Doug: As you go to a new page with a fragment identifier, you update to that fragment identifier. That solves Tantek's problem.
336. # [01:53] <fantasai> Tantek: Multiple navigation with a child?
337. # [01:53] <fantasai> jdaggett: If you have 2 elements that are paginated
338. # [01:54] <fantasai> Tantek: You'd have to scope per fragment the navigation rules if you have a paged child inside a paged document
339. # [01:54] <fantasai> glazou: Just use a page break there. Define a page break after your sldies
340. # [01:54] <fantasai> howcome: For slides that's fine. But for a newspaper article you don't want all the newspaper articles in one document.
341. # [01:55] <fantasai> howcome explains url-doc()
342. # [01:56] <fantasai> glazou: I think you shoudl resurrect selectors on the right-hand side. This is too specific to HTML. Should be able to do this in any kind of markup
343. # [01:56] * Quits: anne (annevk@209.119.68.98) (Quit: anne)
344. # [01:56] <fantasai> glazou: Should be able to retrieve URLs from link anywhere in the prose.
345. # [01:56] <fantasai> glazou: Smells like selector on right-hand side of property
346. # [01:56] <TabAtkins_> We have an existing function that can be used here - element()
347. # [01:56] <fantasai> glazou: Looks like attr(link[rel=index], href)
348. # [01:57] <fantasai> Doug: there's nothing HTML-specific about link relationships
349. # [01:57] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
350. # [01:57] * Joins: myakura (myakura@209.119.68.98)
351. # [01:57] <fantasai> glazou: Next step that you are going to take Håkon is showing multiple pages into one single viewport
352. # [01:57] <fantasai> glazou: To be able to select 5th page directly for example.
353. # [01:58] <fantasai> glazou: So I suggest you think about this andput it in your proposal
354. # [01:58] <fantasai> howcome: I'm going ot show you a book I printed in CSS.
355. # [01:59] <fantasai> howcome: This is a replication of {...} from 1879. Each word on exactly the same page.
356. # [02:00] <fantasai> Bert: If I swipe right to the next document, expect that going left brings me back. But that depends on the navigation styles in the other document
357. # [02:01] <fantasai> Steve: I think it's a mistake to put the navigation in the style here. If you want to link together a bunch of document, should have some kind of manifest.
358. # [02:01] <fantasai> plinss: this is outside the scope of CSS, but yes there's a use case for some kind of manifest that expresses these relationships
359. # [02:03] <fantasai> fantasai: The links among documents can be expressed in HTML. The bit that's out-of-scope is mapping those to navigation gestures
360. # [02:03] <fantasai> ...
361. # [02:03] <fantasai> plinss: It should be next and previous
362. # [02:03] <fantasai> howcome: That's already in the HTML, don't need the CSS.
363. # [02:03] <fantasai> Tantek: Request to add a photo of the folks that were here 7 years ago
364. # [02:04] * Quits: jdaggett_ (jdaggett@64.129.229.106) (Quit: jdaggett_)
365. # [02:04] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
366. # [02:04] <fantasai> Steve: I think there's a difference between what happens in a document, which you specify wiht paged-x and paged-y, and what happens across documents, where I don't think it's the role of CSS to say. But getting to the end of a document is an event, and you could say what happens when you get to that event.
367. # [02:04] <fantasai> glazou: I have a lot of comments on your document.
368. # [02:05] * Quits: vhardy (vhardy@192.150.10.201) (Quit: vhardy)
369. # [02:05] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
370. # [02:05] <fantasai> howcome: Email probably works better if we want others to participate as well.
371. # [02:05] <fantasai> howcome: So this is most of what's new in the GCPM. Maybe continue tomorrow?
372. # [02:05] <fantasai> Meeting closed.
373. # [02:05] * Quits: glazou (glazou@64.129.229.106) (Quit: glazou)
374. # [02:05] * Quits: stearns (anonymous@192.150.10.200) (Quit: stearns)
375. # [02:05] <fantasai> book was Digte by Henrik Ibsen
376. # [02:05] * Quits: bradk_ (bradk@64.129.229.106) (Quit: Computer has gone to sleep)
377. # [02:07] * Quits: howcome (howcome@64.129.229.106) (Ping timeout)
378. # [02:07] * Quits: plinss (plinss@64.129.229.106) (Quit: plinss)
379. # [02:07] * Quits: Rossen (Rossen@64.129.229.106) (Ping timeout)
380. # [02:08] * Quits: TabAtkins_ (tabatkins@208.54.5.223) (Ping timeout)
381. # [02:08] * Quits: alexmog- (alexmog@64.129.229.106) (Ping timeout)
382. # [02:08] * Quits: arronei_ (arronei@64.129.229.106) (Ping timeout)
383. # [02:08] * Quits: mollydotcom (mollyh@64.129.229.106) (Quit: mollydotcom)
384. # [02:09] * Quits: sylvaing (sylvaing@64.129.229.106) (Ping timeout)
385. # [02:09] * Quits: kojiishi (kojiishi@64.129.229.106) (Ping timeout)
386. # [02:11] * Quits: tcelik (tantek_@64.129.229.106) (Quit: tcelik)
387. # [02:14] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
388. # [02:15] * Quits: tantek (tantek@64.129.229.106) (Quit: tantek)
389. # [02:15] * Quits: dbaron (dbaron@64.129.229.106) (Ping timeout)
390. # [02:16] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
391. # [02:17] * Joins: BradK_ (bradk@198.228.215.235)
392. # [02:19] * Joins: kojiishi (kojiishi@64.129.229.106)
393. # [02:20] * Quits: BradK (bradk@64.129.229.106) (Ping timeout)
394. # [02:20] * BradK_ is now known as BradK
395. # [02:22] * Quits: kojiishi (kojiishi@64.129.229.106) (Ping timeout)
396. # [02:28] * Joins: arronei_ (arronei@131.107.0.119)
397. # [02:28] * Quits: arronei (arronei@131.107.0.110) (Ping timeout)
398. # [02:35] * Quits: BradK (bradk@198.228.215.235) (Quit: Buh bye)
399. # [04:10] * Quits: myakura (myakura@209.119.68.98) (Client exited)
400. # [04:55] * Joins: stearns (anonymous@209.119.68.98)
401. # [04:59] * Joins: dbaron (dbaron@173.228.28.129)
402. # [05:03] * Quits: stearns (anonymous@209.119.68.98) (Client exited)
403. # [05:03] * Joins: stearns (anonymous@209.119.68.98)
404. # [05:05] * Joins: sylvaing (sylvaing@209.119.68.98)
405. # [05:09] * Joins: glazou (glazou@209.119.68.98)
406. # [05:10] * Quits: glazou (glazou@209.119.68.98) (Quit: glazou)
407. # [05:22] * Joins: arronei (arronei@63.145.238.4)
408. # [05:28] * Quits: arronei (arronei@63.145.238.4) (Ping timeout)
409. # [05:29] * Joins: shepazu (shepazu@128.30.52.169)
410. # [05:33] * Joins: arronei (arronei@63.145.238.4)
411. # [05:34] <arronei> fantasai: you mentioned the template that I should use for the IR. Can you point me to it?
412. # [05:36] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
413. # [05:41] * Joins: dino (dino@75.16.26.133)
414. # [05:51] * Joins: arno (arno@208.87.61.130)
415. # [05:51] * Quits: arno (arno@208.87.61.130) (Quit: Leaving.)
416. # [05:59] * Quits: dbaron (dbaron@173.228.28.129) (Quit: 8403864 bytes have been tenured, next gc will be global.)
417. # [06:16] <arronei> fantasai: ping
418. # [06:20] * Quits: dino (dino@75.16.26.133) (Quit: dino)
419. # [06:48] * Quits: sylvaing (sylvaing@209.119.68.98) (Ping timeout)
420. # [06:56] <fantasai> arronei: pong
421. # [06:57] <fantasai> arronei: http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/reports/implement-report.html
422. # [06:57] <fantasai> arronei: sorry, was studying gradient syntax
423. # [07:03] * Quits: arronei (arronei@63.145.238.4) (Ping timeout)
424. # [07:03] * Joins: florian (florianr@209.119.68.98)
425. # [07:07] * Parts: florian (florianr@209.119.68.98)
426. # [07:33] * Joins: florian (florianr@209.119.68.98)
427. # [07:34] * Parts: florian (florianr@209.119.68.98)
428. # [07:37] * Joins: arronei (arronei@63.145.238.4)
429. # [07:49] * Quits: arronei (arronei@63.145.238.4) (Ping timeout)
430. # [08:11] * Quits: stearns (anonymous@209.119.68.98) (Quit: stearns)
431. # [08:37] * Joins: florian (florianr@209.119.68.98)
432. # [08:53] * Joins: tantek (tantek@70.36.139.219)
433. # [09:05] * Joins: mohawk (5ae69e1c@78.129.202.38)
434. # [09:06] * Quits: mohawk (5ae69e1c@78.129.202.38) (Quit: http://www.mibbit.com ajax IRC Client)
435. # [09:06] * Parts: florian (florianr@209.119.68.98)
436. # [09:55] * Joins: drublic (drublic@93.132.231.203)
437. # [10:22] * Joins: myakura (myakura@209.119.68.98)
438. # [10:30] * Joins: Ms2ger (Ms2ger@91.181.84.233)
439. # [11:29] * Joins: myakura_ (myakura@209.119.68.98)
440. # [11:29] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
441. # [11:35] * Joins: myakura (myakura@209.119.68.98)
442. # [11:35] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
443. # [11:40] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
444. # [11:40] * Joins: myakura (myakura@209.119.68.98)
445. # [13:06] * Joins: myakura_ (myakura@209.119.68.98)
446. # [13:06] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
447. # [13:19] * Joins: myakura (myakura@209.119.68.98)
448. # [13:19] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
449. # [13:51] * Joins: myakura_ (myakura@209.119.68.98)
450. # [13:51] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
451. # [14:22] * Joins: miketaylr (miketaylr@206.217.92.186)
452. # [14:52] * Joins: myakura (myakura@209.119.68.98)
453. # [14:52] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
454. # [14:55] * Joins: myakura_ (myakura@209.119.68.98)
455. # [14:55] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
456. # [14:57] * Joins: stearns (anonymous@209.119.68.98)
457. # [15:00] * Joins: myakura (myakura@209.119.68.98)
458. # [15:00] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
459. # [15:12] * Joins: anne (annevk@209.119.68.98)
460. # [15:41] * Joins: arronei (arronei@63.145.238.4)
461. # [15:45] * Quits: tantek (tantek@70.36.139.219) (Quit: tantek)
462. # [15:48] * Quits: stearns (anonymous@209.119.68.98) (Quit: stearns)
463. # [15:54] * Joins: sylvaing (sylvaing@209.119.68.98)
464. # [15:59] * Quits: anne (annevk@209.119.68.98) (Quit: anne)
465. # [16:01] * Quits: arronei (arronei@63.145.238.4) (Ping timeout)
466. # [16:04] * Quits: myakura (myakura@209.119.68.98) (Client exited)
467. # [16:21] * Joins: arronei (arronei@63.145.238.4)
468. # [16:21] * Joins: stearns (anonymous@63.145.238.4)
469. # [16:30] * Joins: kojiishi (kojiishi@209.119.68.98)
470. # [16:37] * Joins: myakura (myakura@63.145.238.4)
471. # [16:38] * Quits: kojiishi (kojiishi@209.119.68.98) (Ping timeout)
472. # [16:46] * Joins: karl (karlcow@128.30.54.58)
473. # [16:50] <myakura> day one (zero?) minutes: http://www.w3.org/2011/10/30-css-irc
474. # [16:51] * Joins: YUMA (YUMA@63.145.238.4)
475. # [16:55] * YUMA is now known as yuma
476. # [16:55] * Joins: cyril (chatzilla@63.145.238.4)
477. # [16:57] * Joins: plinss (plinss@63.145.238.4)
478. # [16:57] <Ms2ger> RRSAgent, please make the minutes
479. # [16:57] <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-css-minutes.html Ms2ger
480. # [16:58] * Joins: smfr (smfr@63.145.238.4)
481. # [16:58] * Joins: shan (qw3birc@128.30.52.28)
482. # [16:59] <Ms2ger> Present: Luke McPherson (Google), Shane Stevens (Google), Steve Zilles (Adobe), Molly Holzschlag (Invited Expert), Mark Silverman (Adobe), Deepa Subramanian (Adobe), Bert Bos (W3C), Alan Stearns (Adobe), Arno Gourdol (Adobe), Brad Kemper (Invited Expert), Tab Atkins (Google), Elika Etemad (Mozilla), Daniel Glazman (Disruptive Innovations), Koji Ishii (Invited Expert), John Daggett (Mozilla), David Baron (Mozilla), Arron Eicholz (Microsoft), Sylvain Galineau (Mi
483. # [16:59] <Ms2ger> crosoft), John Jansen (Microsoft), Håkon Lie (Opera), Peter Linss (HP), Chris Lilley (W3C), Vincent Hardy (Adobe), Rossen Atanassov (Microsoft)
484. # [16:59] * Quits: yuma (YUMA@63.145.238.4) (Connection reset by peer)
485. # [17:00] <Ms2ger> RRSAgent, please make the minutes
486. # [17:00] <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-css-minutes.html Ms2ger
487. # [17:00] * Joins: YUMA (YUMA@63.145.238.4)
488. # [17:00] <Ms2ger> Present: Luke McPherson (Google), Shane Stevens (Google), Steve Zilles (Adobe), Molly Holzschlag (Invited Expert), Mark Silverman (Adobe), Deepa Subramanian (Adobe), Bert Bos (W3C), Alan Stearns (Adobe), Arno Gourdol (Adobe), Brad Kemper (Invited Expert), Tab Atkins (Google), Elika Etemad (Mozilla), Daniel Glazman (Disruptive Innovations), Koji Ishii (Invited Expert), John Daggett (Mozilla), David Baron (Mozilla), Arron Eicholz (Microsoft)
489. # [17:00] <Ms2ger> Present+ Sylvain Galineau (Microsoft), John Jansen (Microsoft), Håkon Lie (Opera), Peter Linss (HP), Chris Lilley (W3C), Vincent Hardy (Adobe), Rossen Atanassov (Microsoft)
490. # [17:01] <Ms2ger> RRSAgent, please make the minutes
491. # [17:01] <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-css-minutes.html Ms2ger
492. # [17:01] <Ms2ger> That's better
493. # [17:02] * Joins: dbaron (dbaron@63.145.238.4)
494. # [17:03] * Quits: sylvaing (sylvaing@209.119.68.98) (Ping timeout)
495. # [17:04] * Joins: Kai (chatzilla@63.145.238.4)
496. # [17:06] * Joins: nimbupani (Adium@27.7.20.144)
497. # [17:09] * Joins: glazou (glazou@63.145.238.4)
498. # [17:09] <glazou> test
499. # [17:09] * Joins: dino (dino@63.145.238.4)
500. # [17:09] * Joins: JohnJansen (qw3birc@128.30.52.28)
501. # [17:10] * Joins: Tom (tgambet@mcclure.w3.org)
502. # [17:10] * Joins: mihara (mihara@63.145.238.4)
503. # [17:10] * Joins: mollydotcom (mollyh@63.145.238.4)
504. # [17:11] * Joins: jdaggett_ (jdaggett@63.145.238.4)
505. # [17:11] * Joins: dsinger (dsinger@63.145.238.4)
506. # [17:11] * Joins: alexmog (alexmog@63.145.238.4)
507. # [17:11] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
508. # [17:11] * Joins: anne (annevk@63.145.238.4)
509. # [17:12] <Bert> Topic: Round of introductions
510. # [17:12] * Joins: vhardy (vhardy@192.150.10.200)
511. # [17:12] * Joins: shepazu (shepazu@128.30.52.169)
512. # [17:13] <fantasai> http://www.w3.org/Style/CSS/Tracker/products/8
513. # [17:13] <Bert> Topic: Values and units
514. # [17:13] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/193
515. # [17:14] <Bert> fantasai: Issue 193 is about removing <fraction> and <grid>
516. # [17:14] <Bert> ... Not sure they are actually used anywhere.
517. # [17:14] <Bert> ... Apart from unstable modules.
518. # [17:14] <Bert> ... If necessary we can add them back in Level 4
519. # [17:15] <Bert> Florian: Sounds reasonable. No hidden issues?
520. # [17:15] <Bert> Markus: If another spec needs it?
521. # [17:15] <Bert> fantasai: Some modules already define their own units.
522. # [17:15] * Joins: wangsi-wei (wang@63.145.238.4)
523. # [17:16] <Bert> RESOLVED: remove <fraction> and <grid> (ISSUE-193)
524. # [17:16] <Bert> fantasai: ISSUE-195 is next
525. # [17:16] * Joins: gilles (gilles@63.145.238.4)
526. # [17:16] <Bert> ... In CJK
527. # [17:17] <Bert> ... fonts typically have 1em advance.
528. # [17:17] <Bert> ... We have a ch unit.
529. # [17:17] * Joins: bradk (bradk@63.145.238.4)
530. # [17:17] <Bert> ... Compressed CJK fonts do not advance 1em.
531. # [17:17] <Bert> ... Dow we want a new unit for CJK fonts advance?
532. # [17:18] <Bert> Florian: Is font is proportional?
533. # [17:18] <Bert> fantasai: No, for compressed, but still monospaced fonts.
534. # [17:19] <Bert> JohnD: Don't think we should add it.
535. # [17:19] * Quits: shan (qw3birc@128.30.52.28) (Ping timeout)
536. # [17:19] <dsinger> …thinks it might be good to have a FAQ explaining the difference between the working group, the interest group, and the community group...
537. # [17:19] <Bert> ... It is not going to help you.
538. # [17:19] * dsinger oops wrong room, sorry
539. # [17:19] <Bert> fantasai: Our feedback was that conpressed fonnt should be set solid,
540. # [17:19] * Joins: MoZ (MoZ@63.145.238.4)
541. # [17:19] <Bert> JohnD: how do you get the value?
542. # [17:20] <Bert> fantasai: Same way as ch unit.
543. # [17:20] <Bert> JohnD: Did you ceck that fonts actually give that info?
544. # [17:20] <Bert> Koji: [didn't hear]
545. # [17:21] <Bert> ... Definition in Opentype.
546. # [17:21] <Bert> ... "if this table then use that"
547. # [17:21] <fantasai> s/conpressed fonnt/a line consisting only of ideographic characters/
548. # [17:21] <Bert> JohnD: I'm sceptical.
549. # [17:21] <Bert> ... Would like to see a post on www-style, with use-case
550. # [17:21] * Quits: JohnJansen (qw3birc@128.30.52.28) (Ping timeout)
551. # [17:22] <Bert> [A monk or ghost or... enters the room]
552. # [17:23] <Ms2ger> Hi!
553. # [17:23] * Joins: shans (qw3birc@128.30.52.28)
554. # [17:23] <Bert> ACTION koji post use-case on www-style. Then we'l look at actual fonts.
555. # [17:23] * trackbot noticed an ACTION. Trying to create it.
556. # [17:23] <trackbot> Created ACTION-386 - Post use-case on www-style. Then we'l look at actual fonts. [on Koji Ishii - due 2011-11-07].
557. # [17:24] * Joins: kojiishi (kojiishi@222.158.227.129)
558. # [17:24] <Bert> Topic: Positioned layout module
559. # [17:24] <arronei> http://dev.w3.org/csswg/css3-positioning/
560. # [17:24] * Joins: bernd (57981c2a@64.62.228.82)
561. # [17:24] * Joins: florian (qw3birc@128.30.52.28)
562. # [17:24] <Bert> arronei: [shows module on screen]
563. # [17:24] * Joins: JohnJansen (qw3birc@128.30.52.28)
564. # [17:24] <Bert> arronei: Updated with feedback fromlast ftf
565. # [17:25] <arronei> http://wiki.csswg.org/spec/css3-position
566. # [17:25] <Bert> ... See also the issues list
567. # [17:25] * Joins: sylvaing (sylvaing@63.145.238.4)
568. # [17:25] <Bert> ... ... Still need to discuss some things with Tab.
569. # [17:25] * Joins: Rossen (Rossen@63.145.238.4)
570. # [17:25] * Parts: bernd (57981c2a@64.62.228.82)
571. # [17:25] <Bert> ... Today topic is page positinion and centering.
572. # [17:26] <Bert> ... Page position is absolute, but looks a bit like fixed.
573. # [17:26] <Bert> ... Mainly meant for Regions.
574. # [17:26] <Bert> ... A ddeply nested regions can still be positioned relative to page.
575. # [17:26] <Bert> ... If not in a region, position is relative to intial CB.
576. # [17:27] <Bert> ... Possible problems with overlap in that case.
577. # [17:27] <Bert> Howcome: Hard to understand without examples.
578. # [17:28] <Bert> arronei: Regions create new initial containing blocks.
579. # [17:28] <Bert> howcome: Can you put something in a position on page 3, e.g.?
580. # [17:28] * Joins: shan (qw3birc@128.30.52.28)
581. # [17:28] <Bert> ... 'position: page' with offset.
582. # [17:29] <Bert> fantasai: Overlap if you are not on the page you expected to be on.
583. # [17:29] <Bert> arronei: Really focused on regions.
584. # [17:29] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
585. # [17:29] <Bert> fantasai: Don't ike that fallback behavior.
586. # [17:29] <Bert> howcome: Yes, that is a problem.
587. # [17:29] <Bert> ... Page floats don't have that problem.
588. # [17:30] <Bert> ... Next float autom. goes beneath previous one.
589. # [17:30] <Bert> fantasai: page pos. seems to break too easily, and very badly.
590. # [17:30] <Bert> [dicsussion about cases]
591. # [17:31] <Bert> fantasai: At leats with foats everythign remains readable, visiible.
592. # [17:31] <dino> RRSagent, this meeting spans midnight
593. # [17:31] <RRSAgent> ok, dino; I will not start a new log at midnight
594. # [17:31] <Bert> arronei: I hear some concerns. What is general feel?
595. # [17:31] <Bert> Peter: Some cases you may not care so much, e.g., create a watermark.
596. # [17:32] <Bert> arronei: Shall we pull it out then, for now?
597. # [17:32] <Bert> Steve: For named regions, can you use the name?
598. # [17:33] * Quits: shan (qw3birc@128.30.52.28) (Ping timeout)
599. # [17:33] <Bert> fantasai: abs. pos is not the greatest thing with pagination.
600. # [17:33] <stearns> s/named regions/named pages/
601. # [17:33] <Bert> ... This sulution is broken enough to need redesign.
602. # [17:33] <Bert> arronei: Do you already have a better solution?
603. # [17:33] <Bert> fantasai: Not really.
604. # [17:33] * Quits: alexmog (alexmog@63.145.238.4) (Client exited)
605. # [17:34] * Joins: alexmog (alexmog@63.145.238.4)
606. # [17:34] <Bert> arronei: We need something eventually.
607. # [17:34] <Bert> Steve: We'll need some way to make a seq. of pages with each their own structure.
608. # [17:34] <Bert> ... As we said already with howcomes' demo yesterday.
609. # [17:35] <Bert> Tab: Something like float's ability to reposition itself.
610. # [17:35] * Quits: kojiishi (kojiishi@222.158.227.129) (Quit: Leaving...)
611. # [17:35] <Bert> fantasai: important is that it doesn't break horribly if things aren;t exactly as expected.
612. # [17:35] * Quits: drublic (drublic@93.132.231.203) (Connection reset by peer)
613. # [17:35] * Joins: drublic (drublic@93.132.231.203)
614. # [17:36] * Quits: drublic (drublic@93.132.231.203) (Client exited)
615. # [17:36] <dbaron> (various): Changes to the page size, margins, or font size can cause things that were positioned on different pages to be positioned on the same page, so that they overlap.
616. # [17:36] * Joins: kojiishi (kojiishi@222.158.227.129)
617. # [17:36] <Bert> arronei: If you adjust the margins on a page, you may easily get two elet on the same page where you didn't have them before.
618. # [17:36] <fantasai> fantasai: This will break if you either paginate differently or display in scrolled media
619. # [17:36] <Bert> s/elet/elements/
620. # [17:36] <Bert> Alex: Anything available that would work?
621. # [17:36] <Bert> howcome: page floats!
622. # [17:37] <Bert> alex: Still need to get something in top right if you want it in top right.
623. # [17:38] <Bert> [forgot name]: confusion between clearing and positioning.
624. # [17:38] <Bert> ... Position page is not necessarily the feature at risk. It lacks clearing, yes, but if we solve that, we don't have the fallback pb anymore.
625. # [17:39] <Bert> ... Do you propose to pull the feature to solve positionin or solve clearing?
626. # [17:39] <Bert> Florian: both.
627. # [17:40] <Bert> Alex: Exclusion, positioning and floats all needed, 3rd part not done yet.
628. # [17:40] <Bert> howcome: page floats works, in spec and tested in implementation.
629. # [17:40] <Bert> arronei: find middle ground.
630. # [17:41] <Bert> Tab: floats don't overlap, that is the big difference.
631. # [17:41] <Bert> fantasai: My issue is that something that is desgned such that the fallback nearly always fails, is not good.
632. # [17:41] <Bert> ... We can leave it in ED, but shoul dnot be like this in WD.
633. # [17:42] <Bert> Alex: Want to be able to
634. # [17:42] <Bert> ... EGneneral solution for floats is complex.
635. # [17:42] <Bert> ... We eant that, but want excat algos.
636. # [17:42] <Bert> ... postiioning to page is very important.
637. # [17:42] <Bert> ... Needed for pages with exclusions.
638. # [17:42] <Bert> ... Some of their logic will have to be inscripts.
639. # [17:43] <Bert> ... Very hard to do without positioning to page.
640. # [17:43] <Bert> ... [something]
641. # [17:43] <Bert> Tab: only for scripts, you say?
642. # [17:43] <Bert> Alex: Probably.
643. # [17:44] <Bert> fantasai: So that indicates to me the model is broken and you need a better one.
644. # [17:44] <fantasai> Alex^: This will only work well with multiple positioned items if you have script
645. # [17:44] <Bert> Tab: We should not right something that is broken just because we don't have time for the better one yet.
646. # [17:45] <Bert> arronei: We should think about clearing, not decide it right now, but think.
647. # [17:45] <Bert> ... Can put it in Editor's Draft.
648. # [17:45] <Bert> Steve: Put in the ED what tje issue is, and what arguments are,
649. # [17:45] <Bert> fantasai: and look for other solution for same use cases.
650. # [17:45] <Bert> arronei: I can put that in.
651. # [17:46] <Bert> Brad: What does page float not solve that this does?
652. # [17:46] <Bert> Steve: yes.
653. # [17:46] <Bert> Alex: something that is positioned and does not collide with orther things is a page float.
654. # [17:47] <Bert> howcome: We should find use cases and solve the pb.
655. # [17:47] <Bert> Brad: So this is complementary to page floats?
656. # [17:47] <Bert> Alex: In the future we need page floats that can be positioned abs. on a page.
657. # [17:47] * Joins: shan (qw3birc@128.30.52.28)
658. # [17:47] <Bert> ... Don't worry that we will have that some time in the future.
659. # [17:48] <Bert> ... We want more, but what we have is good enough for now.
660. # [17:48] <Bert> Howcome: We want the use cases to be solved, but we also need the fallback. Cannot rely on scripts to solve the fallback.
661. # [17:48] <Bert> fantasai: Good summary!
662. # [17:48] <Bert> Alex: We have no media selector to distinguish scroll from paged.
663. # [17:49] * Joins: drublic (drublic@95.115.8.221)
664. # [17:49] <Bert> Alex: Let's make floats work.
665. # [17:49] <Bert> arronei: Yes, but we need to move this spec. There aren't many issues left.
666. # [17:50] <fantasai> Tab^: It's not about paged vs scrolled. Even within paged media, this breaks if you change the pagination
667. # [17:50] <Bert> ACTION arronei : details issues further and come up with use cases and solve them better (for values and units) and pull page positionin out of WD.
668. # [17:50] * trackbot noticed an ACTION. Trying to create it.
669. # [17:50] <trackbot> Sorry, couldn't find user - arronei
670. # [17:50] * RRSAgent records action 10
671. # [17:50] <Bert> ACTION arron : details issues further and come up with use cases and solve them better (for values and units) and pull page positionin out of WD.
672. # [17:50] * RRSAgent records action 11
673. # [17:50] * trackbot noticed an ACTION. Trying to create it.
674. # [17:50] <trackbot> Created ACTION-387 - : details issues further and come up with use cases and solve them better (for values and units) and pull page positionin out of WD. [on Arron Eicholz - due 2011-11-07].
675. # [17:50] <Bert> arronei: Need to handle the cases were there is overlap.
676. # [17:51] <Bert> arronei: About center positioning:
677. # [17:51] <Bert> ... Very old request.
678. # [17:51] <Bert> ... It is now similar to block-level non-replaced centering with auto margins.
679. # [17:51] <Bert> ... Margin: auto wouldn't work here.
680. # [17:52] <Bert> ... There is a calculation in the spec.
681. # [17:52] <Bert> ... Set 'position: center'
682. # [17:53] <Bert> Alex: bottom positioning is a problem.
683. # [17:53] <Bert> fantasai: This allows us to position out of flow obkects, but stil not in-flow objects.
684. # [17:53] <Bert> ... And that is more important.
685. # [17:54] <Bert> Daniel: Agree.
686. # [17:54] <Bert> Tab: Can use flex box, or grid.
687. # [17:54] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
688. # [17:54] <Bert> dbaron: Proposal is reasonable for positioning.
689. # [17:55] <Bert> ... Could add something about auto margins, not defined currently.
690. # [17:55] <Bert> Tab: horizontal only, or vertical, too.
691. # [17:55] <Bert> dbaron: Symmetric.
692. # [17:55] <Bert> fantasai: No, it is not symmetric.
693. # [17:56] <Bert> arronei: We'll keep this part in the draft.
694. # [17:56] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
695. # [17:56] <Bert> dbaron: you can center vertically with auto margins, in level 2, as long as height is fixed.
696. # [17:57] <Bert> [discussion about case with height: auto]
697. # [17:57] <Bert> arronei: Should work for auto height, so I'll correct that.
698. # [17:58] <Bert> dbaron: For centering in each dimension you need to set four properties and set height.
699. # [17:58] <Bert> arronei: Some other issues in the spec:
700. # [17:58] <Bert> ... No ruby values.
701. # [17:59] <Bert> ... Not sure what a positioned ruby works.
702. # [17:59] <Bert> dbaron: Do the spec need to redefine CSS 2.1 section?
703. # [17:59] <Bert> ... Can't you just say it amends CSS 2.1 for these cases?
704. # [17:59] <Bert> Tab: Do we want to write delta specs?
705. # [18:00] <Bert> Chris: We decided to refer to CSS 2.1 from level 3 modules.
706. # [18:00] <Bert> Tab: Yes, but not the same thing.
707. # [18:00] * Joins: lgombos (Laszlo@63.145.238.4)
708. # [18:00] <Bert> Chris: We decided that level 3 can refer to CSS 2.1 and to other modules.
709. # [18:00] * Quits: vhardy (vhardy@192.150.10.200) (Connection reset by peer)
710. # [18:01] <Bert> Steve: A module is self-consistent. It refers to other specs, of course.
711. # [18:01] * Quits: lgombos (Laszlo@63.145.238.4) (Quit: Leaving)
712. # [18:01] * Quits: Tom (tgambet@mcclure.w3.org) (Client exited)
713. # [18:01] <Bert> fantasai: Modules replace CSS 2.1, also to make tetx more readable.
714. # [18:01] * Joins: Tom (tgambet@mcclure.w3.org)
715. # [18:02] <Bert> ... This spec should not define display types not un CSS 2.1.
716. # [18:02] <Bert> ... Flex Box defines its own display types and their interaction with this spec.
717. # [18:02] * Joins: lgombos_ (Laszlo@63.145.238.4)
718. # [18:02] * Joins: ChrisL (ChrisL@128.30.52.169)
719. # [18:02] <Bert> arronei: So I only need to refer to 2.1 dusplay types here. OK.
720. # [18:03] <Bert> dbaron: You need to redienf the term "absolutely positioned" to include center aned fixed.
721. # [18:03] <dbaron> http://www.w3.org/TR/CSS21/visuren.html#absolutely-positioned
722. # [18:04] * Joins: lgombos__ (Laszlo@63.145.238.4)
723. # [18:04] * Quits: lgombos_ (Laszlo@63.145.238.4) (Quit: Leaving)
724. # [18:04] * Quits: lgombos__ (Laszlo@63.145.238.4) (Connection reset by peer)
725. # [18:04] * Joins: lgombos (Laszlo@63.145.238.4)
726. # [18:04] <dbaron> http://www.w3.org/TR/CSS21/visuren.html#position-props (positioned)
727. # [18:04] <Bert> arronei: Next is insect-rect.
728. # [18:04] <fantasai> s/insect/inset/
729. # [18:04] <Bert> dbaron: Yes, we resolved to add that some ten years ago :-)
730. # [18:05] <Bert> arronei: So I think we're OK with this part.
731. # [18:05] <Bert> arronei: Last issue is stacking context and opacity and transforms.
732. # [18:05] <Bert> ... Couldn't find any coclusions about that.
733. # [18:06] <Bert> dbaron: Both opacity and transform on elts without z-index, than act as if z-index is 0.
734. # [18:06] <Bert> ... If it is positioned and has a z-index, than use that.
735. # [18:06] <Bert> ... Otherwise do as if z-index is 0.
736. # [18:07] <Bert> arronei: Implementations seem to do that, indeed.
737. # [18:07] <Bert> ... How about transforms?
738. # [18:07] <Bert> dbaron: Believe they ar ethe same.
739. # [18:07] <Bert> arronei: I will add that to this section.
740. # [18:07] <Bert> ... Can we then move this to WD?
741. # [18:08] <Bert> daniel: I think we should. Objections?
742. # [18:08] <Bert> [no objections]
743. # [18:08] <dbaron> see http://lists.w3.org/Archives/Public/www-style/1999Jul/0014.html for inset-rect() :-)
744. # [18:08] <Bert> RESOLVED: publish positionong as WD.
745. # [18:08] <Bert> daniel: One remaark: you cannot actually search for "issue" in the draft.
746. # [18:08] <Bert> ... Can that be fixed?
747. # [18:09] <Bert> fantasai: I think it is a bug in browsers that they don't find generated text.
748. # [18:09] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
749. # [18:09] <Bert> daniel: But we need a way to find issues now.
750. # [18:09] * Joins: vhardy (vhardy@63.145.238.4)
751. # [18:10] <Bert> Topic: Animations
752. # [18:10] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
753. # [18:10] <Bert> [discussion about agenda, break, joint meetings...]
754. # [18:11] <Bert> Daniel: yesterday already some issues.
755. # [18:12] <Bert> Dean: Most editorial issues were addressed already. So we can today talk about difficult issues.
756. # [18:12] * Joins: mmielke (mmielke@63.145.238.4)
757. # [18:12] <Bert> sylvaing: What happens when an anim is cancelled: is there an event?
758. # [18:12] <Bert> dean: You meand, ended before it coempleted
759. # [18:13] <Bert> Dean: What would you do at that point?
760. # [18:13] <Bert> ... Just a notification?
761. # [18:13] <Bert> ... I'd be OK with that.
762. # [18:13] <Bert> sylvaing: Need to put in one place all the things that can happen on cancellation.
763. # [18:13] <Bert> Dean: Give me an action to add an event?
764. # [18:14] <Bert> ... Display: none is tricky.
765. # [18:15] <Bert> sylvaing: People expect that properties continue to change, even if you don't see anything.
766. # [18:15] <Bert> ... But you can achive that with a delay.
767. # [18:15] <Bert> Dean: Computed style of a property exists even when display is none, doesn't it?
768. # [18:15] <Bert> dbaron: starting an animation is result of computing a value.
769. # [18:16] <Bert> ... We don't define *when* you comnpute style.
770. # [18:16] <Bert> ... Just assume it happens at proper time.
771. # [18:16] <Bert> ... Authors depend on display: none not have performance effect.
772. # [18:16] <Bert> ... But changing this will have such a performance effect.
773. # [18:17] <Bert> Shane: not so much impact.
774. # [18:17] <Bert> ... Only look at a selectors that apply.
775. # [18:17] * Joins: tantek (tantek@63.145.238.4)
776. # [18:17] <Bert> sylvaing: Animation delay solves it.
777. # [18:17] <Bert> dbaron: Not so sure about shane's performance assessment. There's also memory, and inheritance.
778. # [18:18] <Bert> shane: It doesn't fundamentally change behavior of 'display: none'
779. # [18:18] <Bert> dbaron: It doesn't change for authors who don't have animations.
780. # [18:18] <Bert> ... But it doesn change where thare are animations.
781. # [18:18] <Bert> shane: Yes, in some cases.
782. # [18:19] <Bert> [discussion about impl. architecture and impat, cscribe didn't udnerstand]
783. # [18:20] <Bert> s/impat/impact/
784. # [18:20] <Bert> Chris: The author expect that hidden stuff is still up to date.
785. # [18:20] <Bert> sylvaing: Use delay.
786. # [18:20] <Bert> Tab: Cannot know delay in advance.
787. # [18:21] <Bert> Dean: Calculate time line in advance for part of the treee
788. # [18:21] <Bert> ... In some future version of the spec we can define that animations can be aligned.
789. # [18:21] <Bert> ... Problem that we cannot do that now.
790. # [18:22] <Bert> ... But we can still say things in current spec so that implementations don't have to compute for elements with display: none.
791. # [18:22] <Bert> ... No events.
792. # [18:22] <Bert> ... You could use script and set delays as well.
793. # [18:22] <Bert> ... What happens if you animate 'display: none' in a key frame?
794. # [18:23] <Bert> Tab: As soon as we can animate keywords, you mean.
795. # [18:23] <Bert> Dean: Yes, that is not yet in spec, but will add it.
796. # [18:23] <Bert> ... I propsoe display: none means element is not animated.
797. # [18:23] <Bert> Luke: What does it mean?
798. # [18:24] <Bert> Dean: Elements with display: none and anumation property, we don't even look at animation.
799. # [18:24] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
800. # [18:24] <Bert> Luke: So as author I first need to set to block, than add animation, so GetComputedStyle(), then set display again.
801. # [18:25] <Bert> Dean: Not sure I understand.
802. # [18:25] <Bert> ... Just set display: inline or whatever and animate.
803. # [18:25] * Joins: dbaron (dbaron@63.145.238.4)
804. # [18:25] <Bert> ... The rules for starting an animation should include that animation starts as soon as display changes from 'none'.
805. # [18:26] <Bert> Shane: Could get interesting.
806. # [18:26] <Bert> ... Change in display may trigger an animation.
807. # [18:26] <Bert> Dean: Is that any worse than applying animation styles? Performance hit?
808. # [18:27] * Joins: cyril (chatzilla@63.145.238.4)
809. # [18:27] <Bert> arronei: Problem if middle key frame has 'display: none'
810. # [18:27] <Bert> s/arronei/sylvain./
811. # [18:28] <Bert> brad: Say I want to move from left to right in 10 sec, and after 5 secs I set display.
812. # [18:29] <Bert> dbaron: So question is if display becomes none in middle of animation and then becomes block again, does animation continue? Gecko does that.
813. # [18:29] <Bert> Brad: So I can stop animation that way and get my use case?
814. # [18:30] <Bert> [Scribe didn't understand]
815. # [18:30] <Bert> Florian: Spec doesn't really say it has to be that way.
816. # [18:31] <Bert> Tab: Say 'display: none' is set during animation.
817. # [18:31] <Bert> dbaron: We recompute style while the animation is running.
818. # [18:31] <Bert> Tab: It won't restart until the display: none goes away?
819. # [18:32] <Bert> ... Mental model is not obvious.
820. # [18:32] <Bert> Florian: Simpelr to say display: none doesn't animate?
821. # [18:32] <Bert> sylvaing: We still need to define
822. # [18:33] <Bert> Shane: Should we look at implications for perf. of running in display: none?
823. # [18:33] <Bert> Markus: Also look at battery life.
824. # [18:33] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
825. # [18:34] <Bert> Dbaron: Animation can stop while display: none is in effect, you still need to detect that.
826. # [18:34] <Bert> Luke: No need to do that in real time.
827. # [18:34] <Bert> dbaron: Yes, need to do that at each tick.
828. # [18:34] * Quits: MoZ (MoZ@63.145.238.4) (Quit: This computer has gone to sleep)
829. # [18:34] <Bert> Luke: What if element itself is removed?
830. # [18:34] <Bert> dbaron: We remove the animation as well.
831. # [18:35] * Quits: myakura (myakura@63.145.238.4) (Client exited)
832. # [18:35] <Bert> Tab: It doens't have any CSS anymore at hat point, that is a distinct case.
833. # [18:35] <Bert> dbaron: We explicitly stop animations when an element moves in the DOM.
834. # [18:36] <Bert> ... We have the code to preserve animations during display: none' preceisley to deal with the DOM issues.
835. # [18:36] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
836. # [18:37] * Joins: szilles (chatzilla@63.145.238.4)
837. # [18:37] <Bert> ... Harder to do if an ancestor has 'display:none' instead of the elet itself.
838. # [18:38] <Bert> Tab: Model is really confusing, except if you undertsnad browser kernels...
839. # [18:38] <Bert> Tab: Simplest is that animations keep running, even if not displayed.
840. # [18:39] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
841. # [18:39] * mollydotcom the room is getting very warm
842. # [18:40] * Joins: dbaron (dbaron@63.145.238.4)
843. # [18:40] <Bert> [scribe missed some]
844. # [18:40] * glazou mollydotcom we'll start air cond during the break
845. # [18:40] <Bert> Dean: Take a spinner, and you set 'display: none' to hide it and expect it to start from zero when it reappears.
846. # [18:41] * Joins: myakura (myakura@63.145.238.4)
847. # [18:41] * Joins: tantek (tantek@63.145.238.4)
848. # [18:41] <Bert> Tab: [explains an solution]
849. # [18:41] <Bert> ... Instead of putting anim. on spinner. set it on spinner.shown.
850. # [18:41] <Bert> ... No restarting involved.
851. # [18:41] <Bert> ... Just add/remove the class when needed.
852. # [18:42] * Quits: Tom (tgambet@mcclure.w3.org) (Ping timeout)
853. # [18:43] * Quits: karl (karlcow@128.30.54.58) (Client exited)
854. # [18:43] * Quits: vhardy (vhardy@63.145.238.4) (Ping timeout)
855. # [18:43] * Quits: gilles (gilles@63.145.238.4) (Ping timeout)
856. # [18:43] * Quits: YUMA (YUMA@63.145.238.4) (Ping timeout)
857. # [18:43] * Quits: alexmog (alexmog@63.145.238.4) (Ping timeout)
858. # [18:44] * Quits: glazou (glazou@63.145.238.4) (Ping timeout)
859. # [18:44] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Ping timeout)
860. # [18:44] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
861. # [18:44] * Quits: tantek (tantek@63.145.238.4) (Ping timeout)
862. # [18:44] * Quits: myakura (myakura@63.145.238.4) (Ping timeout)
863. # [18:44] * Quits: stearns (anonymous@63.145.238.4) (Ping timeout)
864. # [18:44] * Quits: arronei (arronei@63.145.238.4) (Ping timeout)
865. # [18:44] * Quits: mollydotcom (mollyh@63.145.238.4) (Ping timeout)
866. # [18:44] * Quits: dino (dino@63.145.238.4) (Ping timeout)
867. # [18:44] * Quits: plinss (plinss@63.145.238.4) (Ping timeout)
868. # [18:44] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
869. # [18:44] * Quits: kimberlyblessing (Kimberly@63.145.238.4) (Ping timeout)
870. # [18:44] * Quits: smfr (smfr@63.145.238.4) (Ping timeout)
871. # [18:44] * Quits: dsinger (dsinger@63.145.238.4) (Ping timeout)
872. # [18:44] * Quits: bradk (bradk@63.145.238.4) (Ping timeout)
873. # [18:44] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
874. # [18:44] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
875. # [18:44] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
876. # [18:44] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
877. # [18:44] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
878. # [18:44] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
879. # [18:44] * Quits: wangsi-wei (wang@63.145.238.4) (Ping timeout)
880. # [18:44] * Quits: mihara (mihara@63.145.238.4) (Ping timeout)
881. # [18:45] * Quits: JohnJansen (qw3birc@128.30.52.28) (Ping timeout)
882. # [18:45] * Quits: shan (qw3birc@128.30.52.28) (Ping timeout)
883. # [18:45] * Quits: florian (qw3birc@128.30.52.28) (Ping timeout)
884. # [18:47] * Joins: dino (dino@63.145.238.4)
885. # [18:47] * Joins: mmielke (mmielke@63.145.238.4)
886. # [18:47] * Joins: alexmog (alexmog@63.145.238.4)
887. # [18:47] * Joins: sylvaing (sylvaing@63.145.238.4)
888. # [18:47] * Joins: glazou (glazou@63.145.238.4)
889. # [18:47] * Joins: arronei (arronei@63.145.238.4)
890. # [18:47] * Joins: Rossen (Rossen@63.145.238.4)
891. # [18:47] * Joins: gilles (gilles@63.145.238.4)
892. # [18:47] * Quits: shepazu (shepazu@128.30.52.169) (Ping timeout)
893. # [18:47] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
894. # [18:47] * Joins: wangsi-wei (wang@63.145.238.4)
895. # [18:47] * Joins: plinss (plinss@63.145.238.4)
896. # [18:47] * Joins: ChrisL2 (ChrisL@128.30.52.169)
897. # [18:47] * Joins: Kai (chatzilla@63.145.238.4)
898. # [18:47] <Bert> [some discussion not minuted during netwok outage]
899. # [18:47] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
900. # [18:47] * Joins: jdaggett_ (jdaggett@63.145.238.4)
901. # [18:47] * Joins: szilles (chatzilla@63.145.238.4)
902. # [18:47] * Joins: smfr (smfr@63.145.238.4)
903. # [18:47] * Joins: karl (karlcow@128.30.54.58)
904. # [18:47] <Bert> Molly: When displauy is none, animation should not apply.
905. # [18:47] * Joins: Tom (tgambet@mcclure.w3.org)
906. # [18:47] <Bert> ... That is easy to explain.
907. # [18:47] * Joins: myakura (myakura@63.145.238.4)
908. # [18:47] * Joins: YUMA (YUMA@63.145.238.4)
909. # [18:47] * Joins: kojiishi_ (kojiishi@63.145.238.4)
910. # [18:48] * Quits: kojiishi (kojiishi@222.158.227.129) (Quit: Leaving...)
911. # [18:48] <Bert> sylvaing: But what if display is set to none in middle of key frame?
912. # [18:48] * Quits: kojiishi_ (kojiishi@63.145.238.4) (Quit: Leaving...)
913. # [18:48] * Joins: dbaron (dbaron@63.145.238.4)
914. # [18:48] * Joins: kojiishi (kojiishi@63.145.238.4)
915. # [18:48] <Bert> molly: Keep consistent.
916. # [18:48] * Joins: cyril (chatzilla@63.145.238.4)
917. # [18:48] * Quits: mmielke (mmielke@63.145.238.4) (Quit: mmielke)
918. # [18:48] * Joins: bradk (bradk@63.145.238.4)
919. # [18:48] <Bert> Florian: Set none at 50% just kills the animation, that is consisytent.
920. # [18:48] * Joins: mmielke (mmielke@63.145.238.4)
921. # [18:48] <ChrisL2> Forclarity,I prefer to modify what Molly suggested - when display is none, CSS animation must not apply
922. # [18:49] <ChrisL2> (because smil-based animation does apply when display=none)
923. # [18:49] <Bert> Steve: display triggers a relayout, can use visibility hidden instead.
924. # [18:49] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
925. # [18:49] * Joins: shan (qw3birc@128.30.52.28)
926. # [18:49] <Bert> ... So letting display: none turn off anim seems reasonable.
927. # [18:50] <Bert> Markus: Steve's solution is good.
928. # [18:51] <Bert> dbaron: So I hear consensus that display: none breaks animations, stops them.
929. # [18:51] <Bert> RESOLVED: Two new co-editors Sylvain and David
930. # [18:51] <dbaron> RESOLVED: CSS animations do not start or continue running on elements that are display:none or inside display:none elements
931. # [18:52] <Bert> s/David/ for Animations module.
932. # [18:52] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
933. # [18:52] * Quits: wangsi-wei (wang@63.145.238.4) (Quit: wangsi-wei)
934. # [18:53] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
935. # [18:53] <Bert> [break]
936. # [18:53] * Joins: mihara (mihara@63.145.238.4)
937. # [18:53] * Quits: smfr (smfr@63.145.238.4) (Quit: smfr)
938. # [18:53] * Quits: YUMA (YUMA@63.145.238.4) (Ping timeout)
939. # [18:54] * Quits: shan (qw3birc@128.30.52.28) (Ping timeout)
940. # [18:54] * Joins: MoZ (MoZ@63.145.238.4)
941. # [18:54] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
942. # [18:55] <Bert> i/Present:/Scribe: Bert/
943. # [18:56] * Quits: Kai (chatzilla@63.145.238.4) (Ping timeout)
944. # [18:57] * Joins: plinss (plinss@63.145.238.4)
945. # [18:57] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
946. # [18:58] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
947. # [19:00] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
948. # [19:01] * Quits: mihara (mihara@63.145.238.4) (Ping timeout)
949. # [19:02] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
950. # [19:02] * Quits: kimberlyblessing (Kimberly@63.145.238.4) (Connection reset by peer)
951. # [19:02] * Joins: sylvaing (sylvaing@63.145.238.4)
952. # [19:02] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
953. # [19:04] * Joins: wangsi-wei (wang@63.145.238.4)
954. # [19:05] * Joins: mmielke (mmielke@63.145.238.4)
955. # [19:05] * Joins: nimbupani (Adium@27.7.20.144)
956. # [19:05] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
957. # [19:06] * Quits: wangsi-wei (wang@63.145.238.4) (Quit: wangsi-wei)
958. # [19:06] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
959. # [19:10] * Joins: lgombos (Laszlo@63.145.238.4)
960. # [19:10] * Joins: anne (annevk@63.145.238.4)
961. # [19:10] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
962. # [19:10] * Joins: smfr (smfr@63.145.238.4)
963. # [19:10] * Joins: Rossen (Rossen@63.145.238.4)
964. # [19:11] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
965. # [19:11] * Quits: dino (dino@63.145.238.4) (Quit: dino)
966. # [19:11] * Joins: plinss (plinss@63.145.238.4)
967. # [19:11] * Joins: shepazu (shepazu@128.30.52.169)
968. # [19:11] * Joins: stearns (anonymous@63.145.238.4)
969. # [19:12] * Joins: mihara (mihara@63.145.238.4)
970. # [19:12] * Joins: florian (florianr@63.145.238.4)
971. # [19:12] * Joins: dino (dino@63.145.238.4)
972. # [19:13] * Joins: szilles (chatzilla@63.145.238.4)
973. # [19:13] <Bert> [Joint meeting with WebApps, see their minutes]
974. # [19:13] * Quits: ChrisL2 (ChrisL@128.30.52.169) (Ping timeout)
975. # [19:13] * Joins: mmielke (mmielke@63.145.238.4)
976. # [19:13] <glazou> see #webapps
977. # [19:13] * Joins: tantek (tantek@63.145.238.4)
978. # [19:13] <Bert> [See #webapps]
979. # [19:13] * Joins: tcelik (tantek_@63.145.238.4)
980. # [19:14] * Joins: wangsi-wei (wang@63.145.238.4)
981. # [19:14] * Quits: kimberlyblessing (Kimberly@63.145.238.4) (Ping timeout)
982. # [19:16] * Joins: mollydotcom (mollyh@63.145.238.4)
983. # [19:16] * Joins: gilles (gilles@97.158.212.169)
984. # [19:17] * Joins: Kai (chatzilla@63.145.238.4)
985. # [19:19] * Quits: cyril (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 3.6/20100115144158])
986. # [19:20] * Joins: dsinger (dsinger@63.145.238.4)
987. # [19:20] * Joins: cyril (chatzilla@63.145.238.4)
988. # [19:22] * Quits: mihara (mihara@63.145.238.4) (Client exited)
989. # [19:25] <Ms2ger> ACTION Tab to write proposed example text for CORS
990. # [19:25] * trackbot noticed an ACTION. Trying to create it.
991. # [19:25] <trackbot> Created ACTION-388 - Write proposed example text for CORS [on Tab Atkins Jr. - due 2011-11-07].
992. # [19:26] <glazou> Ms2ger: you're in the webapps room ?
993. # [19:26] <Ms2ger> Yes
994. # [19:26] <glazou> ooooh
995. # [19:26] <Ms2ger> The IRC room, that is
996. # [19:26] <glazou> ah
997. # [19:27] <glazou> not physically at tpac
998. # [19:27] <Ms2ger> No, physically I'm sitting in my bedroom :)
999. # [19:27] * Joins: BradK (bradk@63.145.238.4)
1000. # [19:28] <glazou> k
1001. # [19:28] * Quits: florian (florianr@63.145.238.4) (Ping timeout)
1002. # [19:28] <glazou> Ms2ger: please don't file action items for CSS WG
1003. # [19:29] <Ms2ger> OK
1004. # [19:29] <glazou> thanks
1005. # [19:34] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
1006. # [19:35] * Quits: stearns (anonymous@63.145.238.4) (Ping timeout)
1007. # [19:39] * Joins: chsiao (chatzilla@63.145.238.4)
1008. # [19:39] <Bert> rrsagent, pointer?
1009. # [19:39] <RRSAgent> See http://www.w3.org/2011/10/31-css-irc#T18-34-25
1010. # [19:40] * Joins: arno (arno@192.150.10.200)
1011. # [19:40] <Bert> rrsagent, make minutes
1012. # [19:40] <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-css-minutes.html Bert
1013. # [19:42] * Joins: szilles (chatzilla@63.145.238.4)
1014. # [19:42] <Bert> s/Sylvain and David/Sylvain and David for Animations module/
1015. # [19:43] <Bert> s/netwok/network/
1016. # [19:43] <Bert> s/undertsnad/understand/g
1017. # [19:44] <Bert> s/preceisley/precisely/
1018. # [19:44] <Bert> s/doens't/doesn't/g
1019. # [19:45] * Quits: Tom (tgambet@mcclure.w3.org) (Client exited)
1020. # [19:45] <Bert> s/at hat point/at that point/
1021. # [19:45] * Joins: Tom (tgambet@mcclure.w3.org)
1022. # [19:45] <Bert> s/perf./performance/
1023. # [19:46] <Bert> s/Simpelr/Simpler/
1024. # [19:46] * Quits: Tom (tgambet@mcclure.w3.org) (Client exited)
1025. # [19:46] * Joins: Tom (tgambet@mcclure.w3.org)
1026. # [19:47] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
1027. # [19:48] * Joins: Evan_ (qw3birc@128.30.52.28)
1028. # [19:49] * Quits: dino (dino@63.145.238.4) (Quit: dino)
1029. # [19:53] * Joins: tobie (tobie@63.145.238.4)
1030. # [19:55] * Quits: Evan_ (qw3birc@128.30.52.28) (Quit: Page closed)
1031. # [19:55] * Joins: Evan_ (qw3birc@128.30.52.28)
1032. # [19:55] * Quits: Evan_ (qw3birc@128.30.52.28) (Quit: Page closed)
1033. # [20:00] * Joins: gilles_ (gilles@63.145.238.4)
1034. # [20:01] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
1035. # [20:01] * Quits: gilles (gilles@97.158.212.169) (Ping timeout)
1036. # [20:01] * gilles_ is now known as gilles
1037. # [20:03] * Joins: Evan_ (qw3birc@128.30.52.28)
1038. # [20:07] * Quits: Evan_ (qw3birc@128.30.52.28) (Quit: Page closed)
1039. # [20:10] * Quits: mollydotcom (mollyh@63.145.238.4) (Quit: mollydotcom)
1040. # [20:10] * Quits: tobie (tobie@63.145.238.4) (Quit: tobie)
1041. # [20:10] * Quits: smfr (smfr@63.145.238.4) (Quit: smfr)
1042. # [20:11] * Quits: wangsi-wei (wang@63.145.238.4) (Quit: wangsi-wei)
1043. # [20:11] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
1044. # [20:11] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
1045. # [20:11] * Quits: tcelik (tantek_@63.145.238.4) (Quit: tcelik)
1046. # [20:11] * Joins: jdaggett_ (jdaggett@63.145.238.4)
1047. # [20:11] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
1048. # [20:11] * Quits: glazou (glazou@63.145.238.4) (Connection reset by peer)
1049. # [20:12] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
1050. # [20:12] * Joins: glazou (glazou@63.145.238.4)
1051. # [20:12] * Joins: plinss (plinss@63.145.238.4)
1052. # [20:12] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
1053. # [20:12] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
1054. # [20:12] * Joins: smfr (smfr@63.145.238.4)
1055. # [20:13] * Joins: BradK_ (bradk@198.228.214.228)
1056. # [20:14] * Quits: BradK (bradk@63.145.238.4) (Connection reset by peer)
1057. # [20:14] * Joins: sylvaing (sylvaing@63.145.238.4)
1058. # [20:14] * BradK_ is now known as BradK
1059. # [20:15] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
1060. # [20:15] * Joins: Tom_ (tgambet@mcclure.w3.org)
1061. # [20:15] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
1062. # [20:15] * Joins: dino (dino@63.145.238.4)
1063. # [20:16] * Joins: shan_ (qw3birc@128.30.52.28)
1064. # [20:16] * Joins: florian (florianr@63.145.238.4)
1065. # [20:17] * Joins: gilles (gilles@63.145.238.4)
1066. # [20:18] * Quits: kojiishi (kojiishi@63.145.238.4) (Ping timeout)
1067. # [20:18] * Quits: MoZ (MoZ@63.145.238.4) (Quit: This computer has gone to sleep)
1068. # [20:18] * Quits: BradK (bradk@198.228.214.228) (Quit: Buh bye)
1069. # [20:19] * Quits: Tom (tgambet@mcclure.w3.org) (Ping timeout)
1070. # [20:19] * Joins: Rossen (Rossen@63.145.238.4)
1071. # [20:19] * Joins: mihara (mihara@63.145.238.4)
1072. # [20:20] * Joins: kojiishi (kojiishi@63.145.238.4)
1073. # [20:20] <dbaron> [11am-noon was a joint meeting, scribed in #webapps]
1074. # [20:20] <fantasai> RRSAgent: make logs public
1075. # [20:20] <RRSAgent> I have made the request, fantasai
1076. # [20:20] <fantasai> ScribeNick: fantasai
1077. # [20:20] <fantasai> Topic: Animations (cont)
1078. # [20:20] <fantasai> sylvaing: Issue is what if a property is not specified in all keyframes.
1079. # [20:20] <fantasai> sylvaing: Also what if one keyframe has an invalid value
1080. # [20:20] <Bert> Topic: animations [cont'd]
1081. # [20:20] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
1082. # [20:21] * Joins: BradK (bradk@63.145.238.4)
1083. # [20:21] <fantasai> dbaron: What happens in gecko when a property is not valid in all keyframes: every animations animates all properties that are in any keyframe of the animation, over the entire duration of the animation
1084. # [20:21] * Bert won't scribe if fantasai does...
1085. # [20:21] <fantasai> dbaron: The animation interpolates each property across the keyframes from the keyframes in which the property was present.
1086. # [20:21] <fantasai> dbaron gives an example
1087. # [20:21] * Joins: stearns (anonymous@63.145.238.4)
1088. # [20:22] <fantasai> smfr: Imagine exploding keyframes into keyframes per property. For keyframes in which the property isn't specified, you ignore them.
1089. # [20:22] * Joins: tantek_ (tantek@63.145.238.4)
1090. # [20:22] * Quits: tantek (tantek@63.145.238.4) (Connection reset by peer)
1091. # [20:22] * tantek_ is now known as tantek
1092. # [20:23] <fantasai> dbaron: The fun case there, and one I'm not sure we agree on, is what happens if some of the values are value syou cannot interpolate between
1093. # [20:23] <TabAtkins_> sylvaing: So if I had an animation with keyframes at 0%, 50% and 100%, and 'width' appeared only in 0% and 100%, it just animates between those two values and ignores 50% (for 'width')
1094. # [20:23] <fantasai> dbaron: In Gecko, if there are such values, I drop the property from animatio completely
1095. # [20:23] <fantasai> dbaron: So if you animate from width: 100% to width: 50% to width: auto, I say you can't animate between 50% and auto, so I'm not going to animate 'width' at all
1096. # [20:24] <fantasai> Luke: If you have, say, an abspos div and it's specified left in the initial state and right in the final state, you can't actually do an animation for that thing.
1097. # [20:24] <fantasai> smfr: same problem as not being able to animate t/from auto
1098. # [20:24] <fantasai> dbaron: Another issue here from testcase on www-style last week (from Lea?)
1099. # [20:24] <fantasai> dbaron: In some cases, the computed value of one prop depends on computed value of another property
1100. # [20:25] <fantasai> dbaron: If your animation is multiple properties, what basis values are you using?
1101. # [20:25] <fantasai> dbaron: So in Gecko, I didn't really think about this when implementing, so what I implemented is that it ignores other properties in the animation
1102. # [20:25] <fantasai> dbaron: That's probably wrong
1103. # [20:25] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
1104. # [20:25] <fantasai> dbaron: If we want this to work right, for some definition of right, things can get pretty complicated quickly
1105. # [20:26] <fantasai> dbaron: So I'm not sure what to do there.
1106. # [20:26] <fantasai> example was animating stuff in ems and font-size (?)
1107. # [20:26] * glazou has to leave for a meeting at 12:30, peter will chair until 1pm
1108. # [20:26] <fantasai> Luke: Has anyone considered doing this in computed space instead of precomputed?
1109. # [20:26] <fantasai> Tab, dbaron: Happens over computed values
1110. # [20:26] * Joins: mmielke (mmielke@63.145.238.4)
1111. # [20:26] <fantasai> Luke: Instead of being mes and whatever, then you'd want these things to be final pixel values
1112. # [20:27] <fantasai> Luke: Instead of ...
1113. # [20:27] <fantasai> dbaron: You want to animate used values instead of computed values. That's hard because it depends on layout. Would rather not go there.
1114. # [20:27] <fantasai> dbaron: I'd be more interested in solving those problems by making things like calc(50% + 2px + auto) work
1115. # [20:27] <fantasai> dbaron: or calc(auto * 0.5)
1116. # [20:28] <fantasai> dbaron: Then it's much easier to solve these problems
1117. # [20:28] <fantasai> smfr: theoretically you could lay out at the final state to find what 'auto' means
1118. # [20:28] <fantasai> dbaron: The problem there is that might depend on other things that animate
1119. # [20:28] <fantasai> smfr: So does Gecko explicitly not do animations that involve 'auto'?
1120. # [20:29] <fantasai> smfr: In WebKit we treat 'auto' as 0
1121. # [20:29] * Joins: dglazkov (u4270@88.198.6.68)
1122. # [20:29] <fantasai> smfr: That makes things like left -> right work
1123. # [20:29] <fantasai> Luke: So if you have these calc() expressions, you can defer layout
1124. # [20:30] <fantasai> dbaron: Yes, you can do the animation on computed values and then you do the layout with the interpreted calc() expression
1125. # [20:30] * Joins: tantek (tantek@63.145.238.4)
1126. # [20:30] <fantasai> dbaron: background-position has a problem, too -- it needs calc
1127. # [20:30] <fantasai> Shane: It's pretty much impossible to animate gradients without deferring layout
1128. # [20:31] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
1129. # [20:31] <fantasai> Shane: For gradients, you can't generate and interpolate a computed state. You need to do layout
1130. # [20:31] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
1131. # [20:31] <fantasai> dbaron: I think we have a lot of agreement on this. We need to write it up.
1132. # [20:31] <fantasai> dbaron: a) How the loop over properties works: properties, the keyframes
1133. # [20:32] <fantasai> dbaron: b) be clear that interpolation happens on computed values (think we say that already)
1134. # [20:32] <fantasai> dbaron: c) Issue on what to do with non-interpolable pairs in the animation
1135. # [20:33] <fantasai> fantasai: dropping it entirely seems like a better idea. More straightforward, and if we later figure out how to interpolate it and people add it, it'll either work or not work (in olde rbrowsers): you don't get this halfway jumpy thing
1136. # [20:34] <fantasai> smfr: If the property is missing from a 100% keyframe and the animation is looping, you could look for the next value in the loop rather than going back to the base value
1137. # [20:34] * Joins: ChrisL (ChrisL@128.30.52.169)
1138. # [20:34] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
1139. # [20:34] <fantasai> fantasai: so if you only have a property specified in one keyframe
1140. # [20:34] <fantasai> smfr: It would go from base value to that value, stay at that value, and then come back down to the base value once you stop animating
1141. # [20:35] <fantasai> sylvaing: next issue is on transition property
1142. # [20:35] * Quits: chsiao (chatzilla@63.145.238.4) (Ping timeout)
1143. # [20:35] <fantasai> sylvaing: Idea was that you could set a duration for all properties
1144. # [20:35] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
1145. # [20:35] * Joins: bradk_ (bradk@63.145.238.4)
1146. # [20:35] <fantasai> sylvaing: and then override that separately
1147. # [20:35] <fantasai> sy And we talked about the none case. We said that if you have 'none' in the list of properties, that kills everything before it
1148. # [20:35] <fantasai> dbaron: Right now none and all can't be part of a list
1149. # [20:35] <fantasai> sylvaing: We agreed to fix that
1150. # [20:35] <fantasai> dbaron: Missed that thread
1151. # [20:36] * Quits: BradK (bradk@63.145.238.4) (Quit: Buh bye)
1152. # [20:36] <fantasai> dbaron: Seems like it makes more sense for all than none. Maybe fix it for all and not for none?
1153. # [20:36] * Quits: bradk_ (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
1154. # [20:36] <fantasai> Dean: So you can't put none in a list, but all you can
1155. # [20:37] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
1156. # [20:37] <fantasai> fantasai: so, can you put all anywhere in the list?
1157. # [20:37] <fantasai> sylvaing: It will override anything before it
1158. # [20:37] <fantasai> TabAtkins: So 'all' just happens to be a really big shorthand
1159. # [20:38] <fantasai> fantasai: Reminds me of a request for blocking inheritance. Could do "all: initial" for that
1160. # [20:39] <fantasai> plinss: Anything else on animations?
1161. # [20:39] <dbaron> RESOLVED: 'all' is allowed within lists in 'transition-property' (but 'none' is not). Which item wins works like for shorthands, so it's silly to use 'all' other than at the start of the list, but it's not forbidden.
1162. # [20:39] <fantasai> dean: We had an issue on the animation cancel event -- an event that fires when an animation gets cancelled
1163. # [20:39] * Joins: BradK (bradk@63.145.238.4)
1164. # [20:40] <fantasai> dean: The event fires on the element. But what if the element is removed?
1165. # [20:40] <fantasai> dean: Do you fire on its parent? Or not fire the event?
1166. # [20:40] <fantasai> dbaron: I'm inclined it should fire on the element or it shouldn't fire
1167. # [20:40] <fantasai> dbaron: I'm not sure firing an event on something not in the document is something to do
1168. # [20:41] <fantasai> Tab: Not sure it's a problem. Your target phase is weird. You have events firing at DOM non-elements all the time
1169. # [20:41] <fantasai> dbaron: I'd prefer to ask a DOM Events expert; I'm not one
1170. # [20:41] <fantasai> dean: If we do decide to fire on an element that's no longe rin the DOM, then it obviously can't bubble up to its parent.
1171. # [20:42] <fantasai> dean: Typically people want to listen for events on an ancestor
1172. # [20:42] <fantasai> dean: I'm tempted to say it doesn't fire
1173. # [20:42] <fantasai> Tab: I'm not certain if I want to object yet.
1174. # [20:42] <Bert> s/longe rin/longer in/
1175. # [20:42] * Joins: dsinger (dsinger@63.145.238.4)
1176. # [20:42] <fantasai> Dimitri says something about not getting an event on an event listener
1177. # [20:43] <fantasai> ...
1178. # [20:43] * Joins: JohnJansen (qw3birc@128.30.52.28)
1179. # [20:43] <fantasai> AlexRussell: In webkit [...]
1180. # [20:43] <fantasai> AlexRussell says something about bubbling being useful...
1181. # [20:44] <fantasai> Tab: Ms2ger says that firing a DOM event on a disconnected element should be fine
1182. # [20:44] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
1183. # [20:44] <fantasai> RESOLVED: Fire the event on the disconnected element
1184. # [20:44] * Joins: mollydotcom (mollyh@63.145.238.4)
1185. # [20:44] <fantasai> plinss: Does anyone want to check with other DOM Event experts on that?
1186. # [20:44] <fantasai> dbaron: I'll double-check with smaug as well
1187. # [20:45] <fantasai> plinss: Anything else?
1188. # [20:45] <dbaron> ACTION dbaron to write up description of how animations of properties only in some keyframes work
1189. # [20:45] * trackbot noticed an ACTION. Trying to create it.
1190. # [20:45] <trackbot> Created ACTION-389 - Write up description of how animations of properties only in some keyframes work [on David Baron - due 2011-11-07].
1191. # [20:45] * Ms2ger Please do :)
1192. # [20:45] <fantasai> sylvaing: One interesting piece of feeback from ppl internally using them to dev applications
1193. # [20:45] <dbaron> ACTION dbaron to check with smaug about firing DOM events on disconnected elements
1194. # [20:45] * trackbot noticed an ACTION. Trying to create it.
1195. # [20:45] <trackbot> Created ACTION-390 - Check with smaug about firing DOM events on disconnected elements [on David Baron - due 2011-11-07].
1196. # [20:45] <fantasai> sylvaing: They're trying to animate inset box-shadows to outset box-shadows, and it doesn't work
1197. # [20:45] <fantasai> dean: We could do that..
1198. # [20:45] <Bert> s/feeback/feedback/
1199. # [20:45] <Bert> s/ppl/people/
1200. # [20:45] <fantasai> smfr: I almost did that at one point, but gave up because it seemed a little tricky
1201. # [20:46] * Joins: vhardy (vhardy@192.150.10.201)
1202. # [20:46] <fantasai> smfr: What do you do with spread, if it's nonzero?
1203. # [20:46] <fantasai> dean: I still can't work out how you'd do it.
1204. # [20:47] * Quits: kimberlyblessing (Kimberly@63.145.238.4) (Connection reset by peer)
1205. # [20:47] <fantasai> fantasai: You'd have to bring everything down to zero, then bring it all back up on the other side
1206. # [20:48] <fantasai> dbaron: Could you pretend that instead inset, you use negative numbers?
1207. # [20:49] * Quits: arronei (arronei@63.145.238.4) (Connection reset by peer)
1208. # [20:49] * Joins: arronei (arronei@63.145.238.4)
1209. # [20:49] <fantasai> fantasai: You could define this, but it wouldn't be simple: have to bring the offsets and spread and blur radius down to zero and bring them back up. Do you do that simultaneously, one after the other?
1210. # [20:50] <fantasai> dbaron: If someone comes up with a way to represent all these intermediate states
1211. # [20:50] <fantasai> plinss: You want to make it look like raised above, then you're sinking it down
1212. # [20:50] <fantasai> dbaron: You have to model it with a light source
1213. # [20:51] <fantasai> TabAtkins: The shadows are not necessarily representable by a single light source
1214. # [20:51] * Quits: myakura (myakura@63.145.238.4) (Client exited)
1215. # [20:51] <fantasai> dbaron: Assume the light source is a point at inifite distance, and then only modify the distance fo the box to the canvas
1216. # [20:51] <fantasai> dean: With a special model of physics, we can come up with a model for hte animation of inset to outset box-shadows. :)
1217. # [20:52] * ChrisL wondrs if relativistic effects have been ignored
1218. # [20:52] <fantasai> smfr: Any more serious issues?
1219. # [20:52] <dbaron> assume the light source is 45 degrees from vertical
1220. # [20:52] <Ms2ger> s/inifite/infinite/
1221. # [20:53] <fantasai> Seems we will consider animating inset to outset box-shadows iff someone comes up with a proposal of exactly how that's supposed to work.
1222. # [20:53] <fantasai> plinss: They all have to hit zero at the same time or its going to look stupid
1223. # [20:54] <fantasai> dbaron: I could try writing it up, but not sure it's a high priority
1224. # [20:54] <ChrisL> so the question is hopw to simultaneously animate three properties throuh zero and out the other side without a discontinuity?
1225. # [20:54] <fantasai> fantasai: I think you have more important things on your to-do list :)
1226. # [20:54] <fantasai> szilles: +1 to taht
1227. # [20:54] <fantasai> s/taht/that/
1228. # [20:54] <dbaron> I think it's relatively straightforward to break down each shadow as something created by an infinite light source and a box elevation.
1229. # [20:54] <fantasai> RESOLVED: Will consider animating inset to outset box-shadows iff someone posts a proposal of exactly how that's supposed to work.
1230. # [20:54] <dbaron> assume the infinite light source is at 45 degrees for both endpoints
1231. # [20:55] <Bert> text-combine-horizontal property
1232. # [20:56] <fantasai> Topic: Regexp matching and values of text-combine
1233. # [20:56] <fantasai> Florian: We rejected regexp matching in selectors, but you have to do similar for text-combine
1234. # [20:57] <fantasai> Florian is asking for the ability to make pseudo-elements out of something that matches a regexp
1235. # [20:58] <fantasai> jdaggett: yes, it's a contextual role, but it's far more finely scoped
1236. # [20:59] * Joins: szilles (chatzilla@63.145.238.4)
1237. # [20:59] <fantasai> fantasai: When you're dealing with text-combine, you're doing it as you're evaluating the text. It's not part of selector matching.
1238. # [20:59] <fantasai> Florian: Just a question, not an issue.
1239. # [21:00] <Bert> fantasai: from the spec: " If the content contains any element boundaries this is treated as ‘text-combine-horizontal: none’ on the element and any descendants."
1240. # [21:01] <Bert> ... It's atheoretical box, as soon as you notice a boundary you abort constructing it.
1241. # [21:01] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
1242. # [21:01] <Bert> Tab: OK, clear what is supposed to happen, still have editorial reservations.
1243. # [21:01] * Quits: dbaron (dbaron@63.145.238.4) (Quit: 8403864 bytes have been tenured, next gc will be global.)
1244. # [21:01] <fantasai> <br type=lunch>
1245. # [21:01] * Quits: stearns (anonymous@63.145.238.4) (Quit: stearns)
1246. # [21:01] * Quits: smfr (smfr@63.145.238.4) (Quit: smfr)
1247. # [21:02] * Quits: mollydotcom (mollyh@63.145.238.4) (Quit: mollydotcom)
1248. # [21:02] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
1249. # [21:02] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
1250. # [21:02] * Quits: shan_ (qw3birc@128.30.52.28) (Quit: Page closed)
1251. # [21:02] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
1252. # [21:03] * Quits: florian (florianr@63.145.238.4) (Ping timeout)
1253. # [21:03] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
1254. # [21:03] * Quits: arronei (arronei@63.145.238.4) (Ping timeout)
1255. # [21:03] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
1256. # [21:03] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
1257. # [21:04] * Quits: vhardy (vhardy@192.150.10.201) (Ping timeout)
1258. # [21:05] * Quits: mihara (mihara@63.145.238.4) (Ping timeout)
1259. # [21:05] * Quits: kojiishi (kojiishi@63.145.238.4) (Ping timeout)
1260. # [21:06] * Quits: dino (dino@63.145.238.4) (Quit: dino)
1261. # [21:06] * Joins: BradK_ (bradk@198.228.214.228)
1262. # [21:06] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
1263. # [21:07] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
1264. # [21:08] * Quits: BradK (bradk@63.145.238.4) (Connection reset by peer)
1265. # [21:08] * BradK_ is now known as BradK
1266. # [21:08] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
1267. # [21:12] * Joins: anne (annevk@63.145.238.4)
1268. # [21:17] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
1269. # [21:19] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
1270. # [21:21] * Joins: chsiao (chatzilla@63.145.238.4)
1271. # [21:24] * Joins: shepazu (shepazu@128.30.52.169)
1272. # [21:30] * Joins: myakura (myakura@63.145.238.4)
1273. # [21:31] * Tom_ is now known as Tom
1274. # [21:31] * Joins: stearns (anonymous@63.145.238.4)
1275. # [21:33] * Joins: wippler (cdfa0c98@207.192.75.252)
1276. # [21:33] * Joins: tantek (tantek@63.145.238.4)
1277. # [21:33] * Joins: Mike5 (Mike5@mcclure.w3.org)
1278. # [21:33] * Quits: wippler (cdfa0c98@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
1279. # [21:35] * Joins: plinss (plinss@63.145.238.4)
1280. # [21:35] * Joins: Kai (chatzilla@63.145.238.4)
1281. # [21:36] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
1282. # [21:36] * Joins: plinss (plinss@63.145.238.4)
1283. # [21:36] * Joins: dsinger (dsinger@63.145.238.4)
1284. # [21:37] * Joins: tobie (tobie@63.145.238.4)
1285. # [21:38] <Mike5> tantek, we talking about Web Intents in WebApps WG room
1286. # [21:39] * tantek is eating lunch (CSSWG is taking lunch from 1-2pm)
1287. # [21:41] * Joins: myakura_ (myakura@63.145.238.4)
1288. # [21:42] * Quits: myakura (myakura@63.145.238.4) (Connection reset by peer)
1289. # [21:46] * Joins: karl (karlcow@128.30.54.58)
1290. # [21:47] * Joins: MoZ (MoZ@63.145.238.4)
1291. # [21:49] * Joins: jdaggett_ (jdaggett@63.145.238.4)
1292. # [21:50] * Joins: arronei (arronei@63.145.238.4)
1293. # [21:57] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
1294. # [21:58] * Joins: gilles (gilles@63.145.238.4)
1295. # [21:59] * Joins: BradK_ (bradk@198.228.213.126)
1296. # [21:59] * Quits: BradK (bradk@198.228.214.228) (Ping timeout)
1297. # [21:59] * BradK_ is now known as BradK
1298. # [22:01] * Joins: glazou (glazou@63.145.238.4)
1299. # [22:02] * Joins: dbaron (dbaron@63.145.238.4)
1300. # [22:04] * Joins: dholbert (dholbert@98.248.36.12)
1301. # [22:04] <Bert> </br>
1302. # [22:05] <anne> you realize that ends up in the DOM as <br> right?
1303. # [22:06] * Joins: smfr (smfr@63.145.238.4)
1304. # [22:06] * Joins: bradk_ (bradk@63.145.238.4)
1305. # [22:06] <fantasai> yeah, doesn't matter
1306. # [22:06] <fantasai> it's one break
1307. # [22:06] * Bert : Why should it? It is clearly the end of something, not the beginning.
1308. # [22:06] * Ms2ger compat
1309. # [22:06] * Joins: cyril (chatzilla@63.145.238.4)
1310. # [22:06] * fantasai we're assuming XML syntax
1311. # [22:06] <fantasai> :p
1312. # [22:06] * Ms2ger isn't!
1313. # [22:06] <anne> you forgot the namespace!
1314. # [22:07] <fantasai> whatevver
1315. # [22:07] * Joins: mihara (mihara@63.145.238.4)
1316. # [22:07] <fantasai> ScribeNick: fantasai
1317. # [22:07] * Joins: szilles (chatzilla@63.145.238.4)
1318. # [22:07] * Joins: YUMA (yuma@63.145.238.4)
1319. # [22:07] * Joins: jun (fujisawa@63.145.238.4)
1320. # [22:08] <fantasai> Topic: WebApps/CSSWG Joint Meeting Resolution
1321. # [22:08] * Joins: sylvaing (sylvaing@63.145.238.4)
1322. # [22:08] * Joins: shan (qw3birc@128.30.52.28)
1323. # [22:08] <fantasai> jdaggett: We resolved to make the font loading @font-face same-origin by default
1324. # [22:08] <fantasai> jdaggett: Two actions on me
1325. # [22:08] * Quits: chsiao (chatzilla@63.145.238.4) (Ping timeout)
1326. # [22:09] <fantasai> ACTION jdaggett: Reword how same-origin is described to talk only about HTTP
1327. # [22:09] * trackbot noticed an ACTION. Trying to create it.
1328. # [22:09] * RRSAgent records action 12
1329. # [22:09] <trackbot> Created ACTION-391 - Reword how same-origin is described to talk only about HTTP [on John Daggett - due 2011-11-07].
1330. # [22:09] <fantasai> sylvaing: Wouldn't this be an issue for implementations?
1331. # [22:10] <sylvaing> my question was whether implementations used CORS or From-Origin; it seems we made a decision on using CORS
1332. # [22:10] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
1333. # [22:10] <fantasai> fantasai: So if I linked a font on a different server via ftp, that works around the same-origin restriction?
1334. # [22:10] * Joins: JohnJansen (qw3birc@128.30.52.28)
1335. # [22:11] <fantasai> ACTION jdaggett: Talk with Anne about how to reference the same-origin things "correctly"
1336. # [22:11] * RRSAgent records action 13
1337. # [22:11] * trackbot noticed an ACTION. Trying to create it.
1338. # [22:11] <trackbot> Created ACTION-392 - Talk with Anne about how to reference the same-origin things "correctly" [on John Daggett - due 2011-11-07].
1339. # [22:11] * Joins: mmielke (mmielke@63.145.238.4)
1340. # [22:11] * Joins: chsiao (chatzilla@63.145.238.4)
1341. # [22:11] <fantasai> Vladimir: ...
1342. # [22:11] <fantasai> jdaggett: This resolution will eliminate the need for an at-risk rule.
1343. # [22:12] <fantasai> sylvaing: Will there ever be a connection between this and From-Origin
1344. # [22:12] <fantasai> Florian: It's CORS
1345. # [22:12] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
1346. # [22:12] <fantasai> jdaggett: Once the action items are complete, there will be another point at which we can rehash if need be
1347. # [22:12] <hober> I didn't think we made a decision to use CORS specifically, only to have a same-origin restriction by default in @font-face
1348. # [22:13] <fantasai> jdaggett: So do we have a resolution?
1349. # [22:13] * Joins: florian (qw3birc@128.30.52.28)
1350. # [22:13] <fantasai> RESOLVED: @font-face will be same-origin by default with the use of CORS to relax.
1351. # [22:14] * Joins: mollydotcom (mollyh@63.145.238.4)
1352. # [22:14] <fantasai> for HTTP
1353. # [22:14] * Bert : to relax restrictions in CORS, the syntax is "Access-Control-Allow-Origin: *" in the HTTP response headers, I believe. Is there anything else needed?
1354. # [22:14] <fantasai> Topic: Flexbox
1355. # [22:14] * Joins: szilles (chatzilla@63.145.238.4)
1356. # [22:15] <fantasai> TabAtkins: I have a couple outstanding issues I need to edit, but we don't need to worry about -- just reslve corner cases with obvious answers
1357. # [22:15] <fantasai> TabAtkins: Other issue: ATM in the spec flex-order takes a <number>, whereas z-index takes an <integer>
1358. # [22:16] <fantasai> TabAtkins: So we can either make flex-order <integer> or z-index <integer> to make consistent
1359. # [22:16] <fantasai> TabAtkins: Prefer <number> because it makes it easier to insert things in between later
1360. # [22:16] <dbaron> s/or z-index <integer>/or z-index <number>/
1361. # [22:16] <fantasai> ChrisL: what's the impact on z-index of changing it?
1362. # [22:17] * Joins: dino (dino@63.145.238.4)
1363. # [22:17] <fantasai> TabAtkins: z-index currently takes <integer>, so this would be expanding it.
1364. # [22:17] <fantasai> smfr: I'm a little uncomfortable with changing z-index
1365. # [22:17] <fantasai> smfr: I see a lot of devs setting z-index to maxint -1
1366. # [22:18] <fantasai> TabAtkins: Would the crazy things ppl do be affected by this change?
1367. # [22:18] <fantasai> TabAtkins: I don't think so
1368. # [22:18] <fantasai> Arron: We don't know.
1369. # [22:18] <fantasai> Molly: I'm afraid.
1370. # [22:19] <fantasai> Molly: Designers don't understand CSS. They just hack around.
1371. # [22:19] <fantasai> Molly: What is going to happen if something changes there?
1372. # [22:19] * Joins: ChrisL (ChrisL@128.30.52.169)
1373. # [22:19] <fantasai> smfr: Whether it breaks depends on the implementation. Opera had a 16-bit implementation at one point
1374. # [22:19] <fantasai> TabAtkins: floats are above our minimums
1375. # [22:19] <fantasai> smfr: You can't represent maxint accurately as a float
1376. # [22:20] <fantasai> TabAtkins: We were talking about required minimum ranges for <integer>
1377. # [22:20] <fantasai> TabAtkins: will almost certainly be below maxint
1378. # [22:21] <fantasai> Florian: Possible ppl are writing floats into their z-index, and their pages currently work only because it gets thrown out
1379. # [22:21] * mollydotcom correction to minutes please "Many designers don't understand CSS, they use properties that we define and understand, but they create hacks to work around implementations or to address a feature they don't know how else to do"
1380. # [22:22] <fantasai> TabAtkins: If we believe that's actually a problem, that there is significant usage in the wild of invalid z-index values, then we have a problem
1381. # [22:22] * Joins: Tom_ (tgambet@mcclure.w3.org)
1382. # [22:22] <fantasai> Markus: what do we lose by not having <number>?
1383. # [22:22] <fantasai> TabAtkins: It's mildly more convenient to use <number>.
1384. # [22:22] <fantasai> Steve: Is the benefit of analyzing this worth the benefit?
1385. # [22:23] <fantasai> fantasai: you can use the BASIC approach and space your numbers by 100
1386. # [22:23] <fantasai> TabAtkins: Make flex-order be <intger> and later evaluate whether to change flex-order and z-index to <number>
1387. # [22:24] <fantasai> RESOLVED: flex-order as <integer>
1388. # [22:24] <fantasai> fantasai: On another note, why do we have flex-order and z-index?
1389. # [22:24] * sylvaing wonders how existing code that parses z-index value will handle a switch to <number>
1390. # [22:25] <fantasai> TabAtkins: I don't care very much, slightly prefer flex-order
1391. # [22:26] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
1392. # [22:26] <Bert> ('nav-index' is also called "index," not "order.")
1393. # [22:26] * ChrisL @molly don't put that in /me or it will be hidden from the minutes
1394. # [22:26] * Quits: Tom (tgambet@mcclure.w3.org) (Ping timeout)
1395. # [22:27] <fantasai> Bert mentions tabindex in CSS
1396. # [22:27] <fantasai> 'nav-index'
1397. # [22:27] * mollydotcom wasn't sure the best way to request a change to minutes in the conversation flow
1398. # [22:27] <mollydotcom> re: z-index: request clarification to early scribed comment: "Many designers don't understand CSS, they use properties that we define and understand, but they create hacks to work around implementations or to address a feature they don't know how else to do"
1399. # [22:28] <fantasai> discussion
1400. # [22:28] <tantek> hearing 'nav-index', /me puts down the TPAC planning wiki page and hurries back to CSS WG
1401. # [22:28] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
1402. # [22:28] * sylvaing z-bikeshedding
1403. # [22:28] <fantasai> Steve: I think 'index' is slightly better because you have to think about what it means, and if you read it you have to look it up
1404. # [22:28] <fantasai> Steve: I think order implies something it isn't
1405. # [22:28] * Joins: jwir3 (qw3birc@128.30.52.28)
1406. # [22:29] <fantasai> Molly: Many people already understand z-index anyway, and in their vocabulary, so it's consistent anyway
1407. # [22:29] <fantasai> holding off until alex is around
1408. # [22:29] * sylvaing thinks we're arguing for consistency with something everyone is confused about
1409. # [22:30] <fantasai> TabAtkins: Last thing is to request WD publication. Last draft is from 2009
1410. # [22:31] * Joins: tpod (tpod@63.145.238.4)
1411. # [22:33] <fantasai> dbaron: One reason I hesitate to rename flex-order to flex-index is because boxflexgroupthing might be flex-index
1412. # [22:33] <fantasai> TabAtkins: Oh, you mean like flex-group
1413. # [22:33] <fantasai> dbaron: I guess flex-group is fine
1414. # [22:33] * Joins: tcelik (tantek_@63.145.238.4)
1415. # [22:34] * Joins: tantek (tantek@63.145.238.4)
1416. # [22:34] * Joins: Tom (tgambet@mcclure.w3.org)
1417. # [22:34] <fantasai> RESOLVED: Publish css3-flexbox as WD pending flex-index/flex-order issue resolution
1418. # [22:35] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
1419. # [22:35] * Quits: tcelik (tantek_@63.145.238.4) (Quit: tcelik)
1420. # [22:35] <fantasai> alex: flex-order changes processing order, not just visual order so I think it should be flex-order
1421. # [22:35] * Joins: tcelik (tantek_@63.145.238.4)
1422. # [22:35] <fantasai> alex: did you go over min-width?
1423. # [22:35] <fantasai> alex: 8, 10, 12
1424. # [22:35] * Quits: tobie (tobie@63.145.238.4) (Quit: tobie)
1425. # [22:36] * Quits: florian (qw3birc@128.30.52.28) (Ping timeout)
1426. # [22:36] <fantasai> alex: abspos children
1427. # [22:36] <TabAtkins_> http://wiki.csswg.org/spec/css3-flexbox#issue-10
1428. # [22:37] <fantasai> alex: We had an issue about issue of abspos elements creating an empty, which is discoverable when justifying
1429. # [22:37] <fantasai> alex: There is no reasonable way to place that hypothetical static position
1430. # [22:38] * Quits: Tom_ (tgambet@mcclure.w3.org) (Ping timeout)
1431. # [22:38] <fantasai> alex: Place where it would have been is inline content, and that gets wrapped in an anonymous ocntainer, and that box is empty.
1432. # [22:38] <fantasai> alex: But justifying with flex-pack shows this placeholder
1433. # [22:39] <fantasai> alex: Positioning a flex-item without a placeholder is tricky
1434. # [22:39] <fantasai> fantasai: Why not define the static position as coinciding with the flexbox
1435. # [22:39] <fantasai> ?
1436. # [22:40] <fantasai> alex: The only thing we don't like is the behavior with flex-pack: justify, and I don't mind it being bad for this case since it makes everything else work better
1437. # [22:41] <fantasai> TabAtkins: So we're embracing the placeholder concept.
1438. # [22:41] <fantasai> Ojan: I don't like that
1439. # [22:42] <fantasai> Ojan: Weren't you proposing to point its static position as being in the middle of the flex-pack space
1440. # [22:42] <fantasai> dbaron: that's a lot of code to special-case an edge case
1441. # [22:42] <fantasai> RESOLVED: abspos elements leave behind placeholders
1442. # [22:42] <fantasai> and all that implies
1443. # [22:43] * Quits: Tom (tgambet@mcclure.w3.org) (Ping timeout)
1444. # [22:43] * Joins: Tom (tgambet@mcclure.w3.org)
1445. # [22:43] <fantasai> http://wiki.csswg.org/spec/css3-flexbox#issue-8
1446. # [22:43] * Joins: Rossen (Rossen@63.145.238.4)
1447. # [22:43] <fantasai> Straw poll: flex-index vs flex-order
1448. # [22:44] <fantasai> jj: order
1449. # [22:44] <fantasai> alex: order
1450. # [22:44] <fantasai> howcome: absain
1451. # [22:44] <fantasai> koji: absain
1452. # [22:44] * Quits: tpod (tpod@63.145.238.4) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
1453. # [22:44] <fantasai> markus: order
1454. # [22:44] <fantasai> tantek: abstain
1455. # [22:44] <fantasai> steve: index
1456. # [22:44] <fantasai> alan: order
1457. # [22:44] <fantasai> florian: abstain
1458. # [22:44] <fantasai> bert: no opinion
1459. # [22:44] <fantasai> ?: index
1460. # [22:45] <fantasai> brad: abstain
1461. # [22:45] <fantasai> smfr: order
1462. # [22:45] <fantasai> dean: abstain
1463. # [22:45] <shan> soonbo_han: index
1464. # [22:45] <fantasai> shane: order
1465. # [22:45] <hober> hober: order
1466. # [22:45] <fantasai> luke: abstain
1467. # [22:45] * Bert so we decided to call it flex-abstain?
1468. # [22:45] * hober waves from another meeting :)
1469. # [22:45] <fantasai> kim, molly, rossen: order
1470. # [22:45] <fantasai> dbaron: order
1471. # [22:45] <fantasai> jdaggett: abstain
1472. # [22:45] <fantasai> sylvaing: order
1473. # [22:45] <fantasai> arronei: order
1474. # [22:46] <fantasai> tab: order
1475. # [22:46] <fantasai> fantasai: index
1476. # [22:46] <fantasai> glazou: I don't care
1477. # [22:46] <fantasai> ChrisL: order
1478. # [22:46] <fantasai> RESOLVED: flex-order
1479. # [22:46] <fantasai> http://wiki.csswg.org/spec/css3-flexbox#issue-12
1480. # [22:47] <fantasai> TabAtkins: This is to consider z-order axis
1481. # [22:47] <fantasai> TabAtkins: as a flex order
1482. # [22:47] <fantasai> TabAtkins: I believe we shouldn't do anything about this right now
1483. # [22:47] <fantasai> TabAtkins: If we want to address stacked layout, which I think we should, we should consider it as another display or part of grid or something else. Don't have all the primitives we really want
1484. # [22:48] <fantasai> TabAtkins: One thing you might want to do, frex, if you have items of different size, you might want to size to the size of the current item, or size to the size of the largestitem so you don't resize as you swap them
1485. # [22:48] <fantasai> TabAtkins: That's a control that you don't have otherwise
1486. # [22:48] <fantasai> dbaron: What's the use case for size based on the one on top?
1487. # [22:48] <fantasai> dbaron: Gecko implements this, and we've never gotten a request for size based on the one on top
1488. # [22:49] <fantasai> Rossen: size otp sounds like a way of deferring layout of the other things, is that your use case?
1489. # [22:49] <fantasai> TabAtkins: Partially
1490. # [22:49] <fantasai> TabAtkins: Have a use case for sizing according to top
1491. # [22:49] <fantasai> TabAtkins: I've seen tab layouts where your headings or whatever are on the side, and the contents of your page are the stack
1492. # [22:50] <fantasai> TabAtkins: You want thema ll to fill the widths. But if you have a tall item and some short items, you don't want the short items to have a long scroll bar
1493. # [22:50] <fantasai> dbaron: Fair enough, but that doesn't seem like flexbox.
1494. # [22:51] * Quits: shan (qw3birc@128.30.52.28) (Ping timeout)
1495. # [22:51] * Quits: BradK (bradk@198.228.213.126) (Ping timeout)
1496. # [22:51] <fantasai> Markus: If we add this we'll have another way to do stacking in addition to z-index and grid
1497. # [22:51] <fantasai> TabAtkins: There's still further things that distinguish this from plain flexbox that make it not a good idea to combine
1498. # [22:52] <fantasai> TabAtkins: Flexbox's alignment primitives are flex-align and flex-pack, which are perpemndicular/ parallel to the flex axis
1499. # [22:52] <fantasai> TabAtkins: If you have stack, then you have two orthogonal axes, and it's not clear which is align and which is pack
1500. # [22:52] <fantasai> TabAtkins: If we were going to tack it onto one of our layout models, grid might be better. not sure if it's the best idea, but semes better than this
1501. # [22:53] <fantasai> Alex ...
1502. # [22:53] <fantasai> Alex: If you take a grid and give it several items, it will give you a stack.
1503. # [22:53] <Bert> (Template Layout once had 'display: card | card-container | card-tab'. Came from a request from Device Independent WG.)
1504. # [22:53] <fantasai> TabAtkins: One final thing that makes me hesitant, I'm not sure if we ant to address in CSS, but if you have tab layout then you prolly want to show the tabs themselves.
1505. # [22:54] <fantasai> TabAtkins: Auto-generated, linked up manually, some old proposals, but don't know how
1506. # [22:54] <fantasai> TabAtkins: in JavaScript it's easy, but may wnat to address it in CSS
1507. # [22:54] <fantasai> Alex: HTML5 control using script and grid and add to HTML5 as necessary
1508. # [22:54] <fantasai> TabAtkins: One problem with script is, the tabs should be accessible.
1509. # [22:54] <fantasai> TabAtkins: Most developers will not and do not in practice hit all of the accessibility goals we want there.
1510. # [22:55] <fantasai> Alex: it needs to be an HTML5 control
1511. # [22:55] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
1512. # [22:55] <fantasai> fantasai: Couldn't you use fragment IDs?
1513. # [22:55] <fantasai> TabAtkins: If we address this automatically somehow via CSS, I doubt we want to tie this into z-index.
1514. # [22:56] * Quits: myakura_ (myakura@63.145.238.4) (Client exited)
1515. # [22:56] <Bert> (http://www.w3.org/Style/Examples/007/target is example using fragment IDs (and :target, thanks to Daniel))
1516. # [22:56] <fantasai> TabAtkins: problem with using z-index is that you want to just deal with the flex items, not everything else on the page
1517. # [22:56] * Joins: BradK (bradk@63.145.238.4)
1518. # [22:57] <fantasai> RESOLVED: Not addressing stack axis in Flexbox
1519. # [22:57] <fantasai> http://wiki.csswg.org/spec/css3-flexbox#issue-14
1520. # [22:57] <fantasai> alex: Do 'before'/ 'after' apply to direction based on writing mode or based on flex order?
1521. # [22:58] <fantasai> TabAtkins: Currently flex-align: start aligns to the beginning of the flex order
1522. # [22:58] <fantasai> alex: flex-align: after goes after the first line (towards the second)
1523. # [22:59] * Joins: gilles (gilles@63.145.238.4)
1524. # [22:59] * Quits: Tom (tgambet@mcclure.w3.org) (Ping timeout)
1525. # [23:01] <fantasai> RESOLVED: logical keywords are flex-relative, not writing-mode-relative, when used in flexbox
1526. # [23:01] <fantasai> http://wiki.csswg.org/spec/css3-flexbox#issue-17
1527. # [23:01] * Joins: florian (florianr@63.145.238.4)
1528. # [23:01] * Joins: howcome (howcome@63.145.238.4)
1529. # [23:01] <fantasai> TabAtkins: Let's say it says width: flex(1)
1530. # [23:02] <fantasai> TabAtkins: And you give it a min-width of 50px.
1531. # [23:02] * Joins: Tom (tgambet@mcclure.w3.org)
1532. # [23:02] <fantasai> TabAtkins: Should this start the flex calculations from 50px?
1533. # [23:02] <fantasai> TabAtkins: Or should it start from zero and then check/correct if necessary?
1534. # [23:02] <fantasai> TabAtkins: This is important if I want to give each item flex of 1, but set a minimum for readability
1535. # [23:02] <fantasai> TabAtkins: If you make it so that everything starts from the minimum width, this breaks
1536. # [23:03] <fantasai> TabAtkins: Everyone will start at their min-width, then they'll flex, and then they'll be different size
1537. # [23:03] <fantasai> TabAtkins: However, that method is easier
1538. # [23:03] <fantasai> TabAtkins: However I think it is a bad enough behavior that it should be changed
1539. # [23:03] <fantasai> TabAtkins: I'm specifying exactly when min/max are taken into account
1540. # [23:03] <fantasai> TabAtkins: Think we should make sure min/max are handled after flexing.
1541. # [23:04] <fantasai> fantasai: I think I agree
1542. # [23:04] <fantasai> dbaron: ...
1543. # [23:04] <fantasai> TabAtkins: The passes are limited and cheap. It's multi-pass layout, but not full layout. Will converge super-fast.
1544. # [23:05] <fantasai> Alex: Don't think it's possible to avoid multiple returns, but very hard to come up with situation that requires more than one return.
1545. # [23:06] <fantasai> dbaron: Assuming we know how to resolve intrinsic sizes in block dimension
1546. # [23:06] <fantasai> but that's another problem entirely
1547. # [23:06] <dbaron> but one I think we should try to solve in this spec
1548. # [23:06] <fantasai> Alex: Let's say you have flex of 1000px, and your max-content is 2000px and min-content is 500px
1549. # [23:07] <fantasai> Alex: min-width is specified to 100 or 0, doesn't matter
1550. # [23:07] <fantasai> Alex: which of min-width will go to the min, is it going to be min-content or min-width?
1551. # [23:08] <fantasai> alex: I think what's supposed to happen, if width is 'auto' then we should look at min-content width
1552. # [23:08] <fantasai> alex: If width is specified, then we should not look at min-content width.
1553. # [23:09] <fantasai> fantasai: I think it makes sense? I think it's consistent with what Tab proposed.
1554. # [23:09] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
1555. # [23:09] <fantasai> TabAtkins: We're working on an implementation, and you're working on an implementation, so we should be able to figure out what's sane
1556. # [23:09] <fantasai> alex: Question is in what cass do we consult min-content, if ever
1557. # [23:10] <fantasai> s/cass/cases/
1558. # [23:10] <fantasai> alex: Default value of min-width is 0
1559. # [23:10] <fantasai> alex: so it's always specified
1560. # [23:10] <fantasai> do we need an 'auto' value for min-width?
1561. # [23:10] <fantasai> alex: ...
1562. # [23:10] <fantasai> alex: Could say minimum is max(min-width, min-content)
1563. # [23:10] <fantasai> alex: Problem with that is you can never have a box that is smaller than min-content
1564. # [23:11] <fantasai> TabAtkins: Could we say by default things can shrink to zero, and if you want min-content as a minimum, you say min-width: min-content
1565. # [23:11] <fantasai> Ojan: Seems non-flexbox specific
1566. # [23:11] <fantasai> alex: Different because flexibility depends on the width
1567. # [23:12] <fantasai> Ojan: To be consisten with
1568. # [23:12] <fantasai> OjaN: if you put min-width: 100px and width: 300px then you'll get 300px
1569. # [23:12] * Quits: MoZ (MoZ@63.145.238.4) (Quit: This computer has gone to sleep)
1570. # [23:12] <fantasai> dbaron: Those don't conflict. If you swap them you get 300px
1571. # [23:13] <fantasai> Rossen: The problem is that if you want to achieve parity with ehavior of table cells floaters abspos or anything else that does shrink-to-fit,
1572. # [23:13] <fantasai> Rossen: min-content is always respected in these types of layout
1573. # [23:13] <fantasai> Rossen: flex in this case doesn't respect the minimum content
1574. # [23:13] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
1575. # [23:13] <fantasai> Rossen: If you have some characters, and default value of min-content is 0, flex will currently shrink all the way down to zero
1576. # [23:13] <fantasai> Rossen: might or might not be what you want
1577. # [23:14] * Joins: vhardy (vhardy@192.150.10.201)
1578. # [23:14] * Joins: szilles (chatzilla@63.145.238.4)
1579. # [23:15] <fantasai> fantasai: How about changing the initial value of 'min-width' to 'auto'
1580. # [23:15] <fantasai> ?
1581. # [23:15] * Quits: Tom (tgambet@mcclure.w3.org) (Ping timeout)
1582. # [23:15] <fantasai> Rossen: When would you not want min-content?
1583. # [23:15] <fantasai> alex: I have a huge long unbreakable line, don't want to follow that
1584. # [23:16] <fantasai> steve: Wouldn't you want the same thing in a table?
1585. # [23:16] <fantasai> TabAtkins: It's easy to do what we want for flexbox. Still means tables are confusing, but everybody else works the same way.
1586. # [23:17] <fantasai> TabAtkins: If you want min-width of 0, set it to zero. If you want min-width of min-content, say so.
1587. # [23:17] * Quits: Ms2ger (Ms2ger@91.181.84.233) (Quit: nn)
1588. # [23:18] * Joins: Mike5 (Mike5@mcclure.w3.org)
1589. # [23:18] <fantasai> RESOLVED: Effective min-width on flexes is a limitation after the initial flex resolution, not while figuring out preferred width of element.
1590. # [23:19] <fantasai> dbaron: The way things need to work for blocks and tables is that min-width doesn't affect the pref width of the element, but affects the pref width of the parent
1591. # [23:19] <fantasai> RESOLVED: minimum width is just min-width: min-content is not an implied minimum
1592. # [23:20] <fantasai> TabAtkins: There was a question when flex-align: stretch combines with 'max-width' smaller than the size of the flexbox so that it can't stretch beyond
1593. # [23:21] <fantasai> s/beyond/fully/
1594. # [23:21] <fantasai> TabAtkins: Proposal is to respect the sizing constraint and then start-align
1595. # [23:22] <fantasai> RESOLVED: proposal accepted
1596. # [23:22] <fantasai> Ojan: Do we want to address visibility: collapse
1597. # [23:22] <TabAtkins_> fantasai: the problem with using display:none to dynamically show/hide elements...
1598. # [23:23] <TabAtkins_> fantasai: ...is that you really only want to take thing out-of-flow in one dimension (the main axis).
1599. # [23:23] * Quits: vhardy (vhardy@192.150.10.201) (Ping timeout)
1600. # [23:23] <Bert> (Example of 'visibility: collapse' in tables: http://www.w3.org/Style/Examples/007/folding)
1601. # [23:24] <TabAtkins_> fantasai: You can't do that with display:none, but visibility:collapse is *supposed* to solve this in tables. It does a bad job, but we cant do it right.
1602. # [23:24] <fantasai> (example was of a panel with collapsing panels)
1603. # [23:24] <TabAtkins_> dbaron: I think it doesn't work well in tables because it hasn't been solved right yet.
1604. # [23:25] <TabAtkins_> dbaron: Because if you have more space for the other things, they can be smaller in the other dimension, so they'll still change size.
1605. # [23:25] <TabAtkins_> fantasai: Tables also have the problem that row/col spans get clipped oddly by collapse.
1606. # [23:25] <TabAtkins_> ojan: My concern with this is that this is sort of a more generic thing. Why doesn't this work on lists (hiding, but still incrementing counters).
1607. # [23:26] <TabAtkins_> fantasai: I'd like it to work there.
1608. # [23:26] <TabAtkins_> ojan: Right, but there's backwards compat issues. So let's ignore collapse, and solve it properly with a new property or value.
1609. # [23:26] <fantasai> dbaron: What's the problem with lists?
1610. # [23:26] <fantasai> that's not solved by display: none?
1611. # [23:26] <fantasai> TabAtkins: Preserving counters.
1612. # [23:27] <fantasai> fantasai: Also contribution of the width to the parent's intrinsic size
1613. # [23:27] <fantasai> TabAtkins: Also, running animations.
1614. # [23:27] <fantasai> Steve: what happens if I set height to zero
1615. # [23:28] <fantasai> fantasai: you also have to turn off padding, border, margins, box-shadow, etc. etc.
1616. # [23:29] <fantasai> Ojan: So it's dead in the water to make visibility: collapse; work on block elements, I presume?
1617. # [23:29] <fantasai> dbaron: I don't know, maybe not
1618. # [23:29] <fantasai> Molly: visibility: collapse isn't taught
1619. # [23:30] <fantasai> ...
1620. # [23:31] * Joins: vhardy (vhardy@192.150.10.200)
1621. # [23:32] <fantasai> fantasai: Goal is to make it not show up, just like display: none; except without some of its problems
1622. # [23:33] * glazou <br type="coffee break" time="15:30:00"/>
1623. # [23:33] <fantasai> Bert asserts that you'd want to leave extra space so that the content after the list stays the same place
1624. # [23:34] <fantasai> fantasai doesn't understand what we're arguing over anymore
1625. # [23:34] * ChrisL wonders idly if clock times are always resolved, in smil
1626. # [23:35] <fantasai> dbaron: sounds like this is unresolved
1627. # [23:35] * Joins: Linuz (linuz.lee@63.145.238.4)
1628. # [23:36] * Joins: shepazu (shepazu@128.30.52.169)
1629. # [23:36] * Quits: smfr (smfr@63.145.238.4) (Quit: smfr)
1630. # [23:36] * Quits: mollydotcom (mollyh@63.145.238.4) (Quit: mollydotcom)
1631. # [23:39] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
1632. # [23:40] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
1633. # [23:40] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
1634. # [23:40] * Quits: jun (fujisawa@63.145.238.4) (Quit: jun)
1635. # [23:42] * Joins: tpod (tpod@63.145.238.4)
1636. # [23:42] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
1637. # [23:43] * Quits: mihara (mihara@63.145.238.4) (Ping timeout)
1638. # [23:43] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
1639. # [23:44] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
1640. # [23:44] * Joins: szilles (chatzilla@63.145.238.4)
1641. # [23:45] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
1642. # [23:48] * Joins: dbaron (dbaron@63.145.238.4)
1643. # [23:48] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
1644. # [23:49] * Joins: shan (soonbo.han@63.145.238.4)
1645. # [23:50] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
1646. # [23:52] * Joins: mihara (mihara@63.145.238.4)
1647. # [23:53] * Joins: jun (fujisawa@63.145.238.4)
1648. # [23:53] <TabAtkins_> scribenick: TabAtkins_
1649. # [23:54] * Joins: smfr (smfr@63.145.238.4)
1650. # [23:54] * Joins: dbaron (dbaron@63.145.238.4)
1651. # [23:54] <TabAtkins_> howcome: multicol is in CR. impls are coming along.
1652. # [23:54] <TabAtkins_> howcome: But there's one area i've discovered wehre we don't hav einterop
1653. # [23:55] <TabAtkins_> howcome: the break-before/after/inside properties
1654. # [23:55] <howcome> http://www.w3.org/TR/css3-multicol/#break-before-break-after-break-inside
1655. # [23:55] <TabAtkins_> howcome: Basic question i need an answer for.
1656. # [23:55] <TabAtkins_> howcome: Applies to both column and page breaks.
1657. # [23:55] <TabAtkins_> howcome: Say you have an element, the first in a page or column. And you set break-before on it.
1658. # [23:55] <TabAtkins_> howcome: Should you apply it (forcing a new break), or just leave it, since it's already the first element.
1659. # [23:56] <TabAtkins_> howcome: I think we should do the latter.
1660. # [23:56] * Joins: mmielke (mmielke@63.145.238.4)
1661. # [23:56] <TabAtkins_> howcome: For both pages and columns.
1662. # [23:56] * Joins: Rossen (Rossen@63.145.238.4)
1663. # [23:57] <TabAtkins_> fantasai: For pages, you sometimes want blank pages, but you don't want *arbitrary* extra blank pages. Usually you want to start all chapters on the left page, or something.
1664. # [23:57] <TabAtkins_> glazou: Sometimes you do specifically always want, say, 1 blank page before chapters.
1665. # [23:58] <TabAtkins_> fantasai: You can do that by using ::before or similar and give it a sufficient height (but no content) to push the rest of the content down.
1666. # [23:58] <TabAtkins_> howcome: 2 out of 3, roughly, do it the way I want.
1667. # [23:58] <ChrisL> <div class="notes" style="page-break-before:always;background-image:tpib.png"/>
1668. # [23:58] <TabAtkins_> howcome: The others force a new break.
1669. # [23:59] <ChrisL> s/tpib/tpilb/
1670. # [23:59] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
1671. # [23:59] <TabAtkins_> glazou: So the proposal is to *not* create a blank column when the first element in a multicol has break-before:always.
1672. # [23:59] <TabAtkins_> RESOLVED: break-before:column won't force a blank column when the element is the first in the column.
1673. # Session Close: Tue Nov 01 00:00:00 2011

The end :)