/irc-logs / w3c / #css / 2011-03-08 / end

Options:

1. # Session Start: Tue Mar 08 00:00:00 2011
2. # Session Ident: #css
3. # [00:00] <Bert> Topic: issue 250
4. # [00:00] <Bert> BB: EE's proposed text looks fine.
5. # [00:00] <Bert> RESOLVED: use EE's proposed text on issue 250.
6. # [00:00] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-252
7. # [00:01] <Bert> Topic: Issue 252
8. # [00:03] <Bert> [Some more discussion about 250: should space not only be allowed, but required? Result: no.]
9. # [00:03] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-253
10. # [00:04] <johnjan> sorry, still on 252
11. # [00:05] <Bert> DB: I think Boris's response is wrong, though.
12. # [00:05] <Bert> -> http://lists.w3.org/Archives/Public/www-style/2011Jan/0092.html Boris's response
13. # [00:06] <Bert> DB: BAD_STRING is not allowed in a block, it seems.
14. # [00:07] <Bert> PL: What does it mean to have a BAD_STRING in a block?
15. # [00:08] <dbaron> I think BAD_* should be in any
16. # [00:09] <Bert> BB: But the grammar defines what is valid, and BAD_STRING is never valid.
17. # [00:09] <Bert> DB: But then we have no rules for dealing with the error.
18. # [00:09] <Bert> BB: Those rules are there: skip to the end of the block (or the decl, as the case may be).
19. # [00:10] <Bert> PL: Do we need to do anything in CSS 2.1?
20. # [00:10] <dbaron> (maybe not BAD_COMMENT)
21. # [00:11] * Joins: dsinger (dsinger@17.73.146.150)
22. # [00:12] <dbaron> 4.1.1 says "The meaning of input that cannot be tokenized or parsed is undefined in CSS 2.1. "
23. # [00:12] <dbaron> and we don't want all this error handling to fall into that clause
24. # [00:12] <Bert> DB: Last sentence of 4.1.1 says unparsable means undefined. But we have error rules.
25. # [00:13] <dbaron> Proposal:
26. # [00:14] <Bert> DB: My proposal is to add BAD_URI and BAD_STRING to the "any" production.
27. # [00:14] * Joins: tantek (tantek@63.245.220.240)
28. # [00:14] <dbaron> ... and then change "COMMENT tokens do not occur" to "COMMENT and BAD_COMMENT tokens do not occur"
29. # [00:18] <Bert> BB: Counterproposal is to leave the grammar dfining valid CSS, and add in 4.1.6. s/any tokens/any tokens (except BAD* tokens)/
30. # [00:19] <Bert> DB: We should remobve the sentence "The meaning of input that cannot be tokenized or parsed is undefined in CSS 2.1.
31. # [00:19] <Bert> ... from 4.1.1
32. # [00:20] <Bert> s/dfining/defining/
33. # [00:20] <Bert> s/remobve/remove/
34. # [00:21] <Bert> PL: It talks about the tokens that cannot be parsed.
35. # [00:21] <Bert> DB: But it makes the whole style sheet undefined.
36. # [00:22] <Bert> AE: Usually we talk about "the part of the style sheet" so this seems to be about the whole style sheet.
37. # [00:23] <Bert> PL: I think parsing is covered by 4.2
38. # [00:25] <Bert> DB: But what makes something a declaation that you can ignore is the grammmar.
39. # [00:26] <dbaron> DB: OK, let's just leave it, and fix it in css3.
40. # [00:26] <Bert> PL: Objection to DB's proposal?
41. # [00:27] <Bert> AE: We can always change it back in errata.
42. # [00:27] <Bert> DB: We can just leave it unchanged.
43. # [00:27] <Bert> RESOLVED: No change in 252
44. # [00:27] * sylvaing still has a few 'I have standards' IE9 t-shirts....
45. # [00:28] * Quits: Ms2ger (Ms2ger@91.181.106.89) (Quit: nn)
46. # [00:31] * gsnedders appears looking vaguely interested
47. # [00:31] <mihara> I ask for Tokyo forum to be discussed in Tue afternoon. I am not here on Wed.
48. # [00:31] * gsnedders (in the t-shirt, not in CSS)
49. # [00:32] * Joins: myakura (myakura@123.224.162.182)
50. # [00:34] <jdaggett> http://www.amazon.com/Avoid-Huge-Ships-John-Trimmer/dp/0870334336/ref=sr_1_1?ie=UTF8&qid=1299540509&sr=8-1
51. # [00:34] <jdaggett> hint: read the comments!
52. # [00:34] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
53. # [00:37] * Quits: hyatt (hyatt@98.200.13.42) (Quit: hyatt)
54. # [00:37] * sylvaing this seems similar to http://www.amazon.com/Mountain-Three-Wolf-Short-Sleeve/dp/B002HJ377A
55. # [00:38] * Quits: myakura (myakura@123.224.162.182) (Client exited)
56. # [00:40] * sylvaing I think this is the t-shirt for gsnedders
57. # [00:47] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-253
58. # [00:50] <Bert> Topic: Issue 253
59. # [00:54] <Bert> PL: Are we OK with the proposed change of [??]?
60. # [00:54] <Bert> DB: Relates to last large DL of 4.2.
61. # [00:55] * gsnedders sylvaing: pff, wolves, not vampires… *shakes head*
62. # [00:55] <Bert> ... Possible to reach end of style sheet and end of string at the same time.
63. # [00:56] * gsnedders sylvaing: there again, I presume the IE9 shirt doesn't haveLayout, so is just a bunch of random shapes scattered over the shirt
64. # [00:57] <Bert> ... Should be more clear what end of line means.
65. # [00:57] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-254
66. # [00:58] <Bert> RESOLVED: say in 4.2 more clearly what end of line means.
67. # [00:59] <Bert> [That means end of line is a particular character from \r\n]
68. # [01:00] <Bert> Topic: Issue 254
69. # [01:01] <Bert> DG: Does this need edits?
70. # [01:01] <Bert> DB: Probably not.
71. # [01:01] <Bert> EE: Issue may be about whether the "-->" i the e-mail is a statement.
72. # [01:02] <Bert> DG: I propose no chnage.
73. # [01:02] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-255
74. # [01:02] <Bert> RESOLVED: no chnage for 254
75. # [01:02] <Bert> Topic: Issue 255
76. # [01:02] <Bert> s/chnage/change/
77. # [01:04] <Bert> JJ: Just say "HTML specifications"
78. # [01:05] <Bert> DG: Cannot reference HTML5 as it is not a REc.
79. # [01:05] * Joins: arno1 (arno@63.245.220.224)
80. # [01:05] * Quits: arno (arno@192.150.10.200) (Ping timeout)
81. # [01:05] <Bert> RESOLVED: "and future versions" added to to section 3.1 for issue 255.
82. # [01:06] <Bert> Topic: issue 256
83. # [01:06] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-256
84. # [01:07] <Bert> DG: Just add "in HTML"
85. # [01:07] <Bert> TC: *any version* of HTML.
86. # [01:08] <Bert> PL: How about XForms?
87. # [01:08] <Bert> ... Leave it as is.
88. # [01:08] <Bert> RESOLVED: No change for issue 256.
89. # [01:09] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-257
90. # [01:09] <Bert> Topic: Issue 257
91. # [01:10] <Bert> PL: I think we do want boxes to have properties.
92. # [01:10] <Bert> DB: I agree.
93. # [01:10] <Bert> PL: So no chnage?
94. # [01:10] <Bert> RESOLVED: no change for issue 257
95. # [01:10] <Bert> Topic: Issue 259
96. # [01:10] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-259
97. # [01:11] <Bert> DG: Indeed the 'inherit' keyword is never the computed value.
98. # [01:12] <Bert> HL: In css3-values, 'inherit' is not the specified value.
99. # [01:12] <Bert> DB: We might have changed that already.
100. # [01:13] <Bert> DG: If 'inherit' is not returned as the specified value, that breaks editors.
101. # [01:13] <Bert> EE: Have to distinguish from what the CSSOM says.
102. # [01:14] <Bert> HL: There is a "cascaded value" also, that is what editors need.
103. # [01:15] <Bert> ... The text in CSS 2.1 is consistent with css3-values.
104. # [01:15] <Bert> PL: So no change?
105. # [01:15] <Bert> JJ: And do something in level 3?
106. # [01:16] <Bert> TA: Better not have level 3 contradict level 2.
107. # [01:16] <Bert> HL/JJ: Bahevior isn't different, there is just different terms: cascaded values.
108. # [01:17] <Bert> EE: Inconsistency between 3 and 2 is the missing term cascaded value.
109. # [01:18] <Bert> ... Could add a note about that.
110. # [01:18] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-260
111. # [01:18] <Bert> ACTION elika: write a proposed text for issue 259
112. # [01:18] * trackbot noticed an ACTION. Trying to create it.
113. # [01:18] * RRSAgent records action 2
114. # [01:18] <trackbot> Created ACTION-310 - Write a proposed text for issue 259 [on Elika Etemad - due 2011-03-15].
115. # [01:19] <Bert> Topic: issue 260
116. # [01:20] <Bert> EE: We added that note to clarify something else. Opinions differ on what is more or less confusing. So no change.
117. # [01:20] <Bert> RESOLVED: no change for issue 260
118. # [01:21] <Bert> Topic: Issue 261
119. # [01:21] <Bert> DG: Nobody ever complained. Seems not worth a chnage.
120. # [01:22] <Bert> PL: Is this already in Selectors spec?
121. # [01:22] <Bert> DG: No, that has the same prose as 2.1.
122. # [01:22] * Quits: arno1 (arno@63.245.220.224) (Quit: Leaving.)
123. # [01:22] * Joins: arno (arno@63.245.220.224)
124. # [01:23] <Bert> PL: No chnage needed. Selectors is a clearer, that's good enough.
125. # [01:23] <Bert> RESOLVED: No change issue 261
126. # [01:24] <Bert> [Discussion about issues list and numbers, duplicates]
127. # [01:25] * Quits: tantek (tantek@63.245.220.240) (Quit: tantek)
128. # [01:25] <Bert> JJ: Issue 262 seems duplicate of 261 and 260.
129. # [01:26] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-262
130. # [01:26] <Bert> Topic: Issue 262
131. # [01:26] <Bert> PL: Propose no change for issue 262.
132. # [01:27] <Bert> RESOLVED: No change issue 262
133. # [01:29] * Joins: homata (homata@58.158.182.50)
134. # [01:30] <Bert> [Discussion about what is best way to deal with minor editorial issues. At this point, just rejecting it is best, no risk of errors.]
135. # [01:30] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-263
136. # [01:31] <Bert> Topic: Issue 263
137. # [01:31] <Bert> SZ: Maybe we can make a boilerplate text for all these editorial rejected issues.
138. # [01:32] <Bert> ... For when we reply to the submitter of the issue.
139. # [01:33] <Bert> PL: Seems same case again: Edit is nice to have, but not needed now.
140. # [01:33] <Bert> RESOLVED: no change for issue 263
141. # [01:33] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-264
142. # [01:33] <Bert> Topic: Issue 264
143. # [01:34] <Bert> DB: We discussed zero-height floats already today.
144. # [01:35] <Bert> JJ: Did the earlier discussion affect this issue?
145. # [01:35] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
146. # [01:35] <Bert> DB: No. The note in the issue is wrong.
147. # [01:36] <Bert> RESOLVED: accept change proposed in the issue e-mail for issue 264.
148. # [01:36] <Bert> Topic: Issue 265
149. # [01:37] <Bert> RESOLVED: No change issue 265
150. # [01:37] <Bert> Topic: Issue 266
151. # [01:38] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-266
152. # [01:39] <Bert> EE: I think we should make the suggested edits, they fix what we missied in the previous round for issue 120.
153. # [01:39] <Bert> JJ: And the ones you were not sure about?
154. # [01:39] <Bert> ... Issue 3 in the linked e-mail.
155. # [01:40] <Bert> [it's about whether table-caption is block-level]
156. # [01:40] <Bert> AE: Doesn't seem to hurt anything to make it block-level.
157. # [01:42] <Bert> EE: If we don't fix it, we'll have to do it in errata anyway.
158. # [01:43] <Bert> [Discussion about how 'overflow' might apply if flex box is added to CSS]
159. # [01:43] <Bert> JJ: So take all of them, except issue 6.
160. # [01:44] <Bert> s/all of/none of/
161. # [01:45] <Bert> EE: What does Bert think?
162. # [01:45] <Bert> BB: I don't know yet.
163. # [01:46] <Bert> RESOLVED: Accept issue 6, defer the others to the errata.
164. # [01:47] <Bert> [Above is for issue 266]
165. # [01:47] <Bert> Topic: Issue 267
166. # [01:47] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-267
167. # [01:47] <Bert> DB: It marches impls that I tested.
168. # [01:47] <Bert> s/marches/matches/
169. # [01:48] <Bert> s/It/The proposed edit/
170. # [01:48] * Joins: sgalineau (sylvaing@63.245.220.224)
171. # [01:48] <dbaron> test is http://dbaron.org/css/test/2011/css21-issue-267
172. # [01:49] <dbaron> (question is which is on top)
173. # [01:49] * Quits: sylvaing (sylvaing@63.245.220.224) (Ping timeout)
174. # [01:49] <dbaron> actually, it doesn't test the issue
175. # [01:49] <Bert> DB: I think it is editorial.
176. # [01:49] <dbaron> actually, hold on
177. # [01:53] <bradk> 268 and 269 should be http://lists.w3.org/Archives/Public/www-style/2011Jan/0087.html right?
178. # [01:53] <Bert> DB: Two browsers do one thing, two do the other.
179. # [01:53] <Bert> ... The proposal matches Opera nd Webkit.
180. # [01:53] <Bert> s/nd/and/
181. # [01:54] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-268
182. # [01:54] <Bert> RESOLVED: Accept propsoed edit for issue 267.
183. # [01:54] <Bert> Topic: Issue 268
184. # [01:56] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-203
185. # [01:56] <johnjan> http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html
186. # [01:56] <Bert> Topic: Issue 203 (again)
187. # [01:56] <Bert> JJ: Anton Prowse disagrees with our resolution.
188. # [01:58] <Bert> -> http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html Anton's message
189. # [02:02] <Bert> DB: The reason for the hypothetical top border is so as not to move the element unnecessarily.
190. # [02:03] <Bert> AE: Test cases are all interoperable.
191. # [02:03] <Bert> ... See margin-collapse-05
192. # [02:05] <Bert> EE: Difficult to keep track of which clearance issues are the same issue.
193. # [02:05] <Arron> s/margin-collapse-05/margin-collapse-clear-005
194. # [02:06] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-268
195. # [02:07] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jan/0644.html
196. # [02:07] <fantasai> resolved in that meeting
197. # [02:08] <Bert> RESOLVED: 203 was already discussed and we allowed two behaviors. (See issues list)
198. # [02:08] <dbaron> s/move the element/move the element up/
199. # [02:08] <Bert> Topic: Issue 268
200. # [02:09] <dbaron> (I'm having trouble working out a testcase for why the hypothetical border edge is useful, though.)
201. # [02:09] <Bert> EE: I thibnk the spec is correct.
202. # [02:10] * Joins: alexmog (qw3birc@128.30.52.28)
203. # [02:10] <dbaron> Though actually, maybe I'm misremembering the purpose.
204. # [02:10] <dbaron> Maybe it's to prevent contradictions.
205. # [02:11] <Bert> s/thibnk/think/
206. # [02:11] * Joins: tantek (tantek@63.245.220.240)
207. # [02:12] <Bert> [People trying to find out what the issue is]
208. # [02:13] <Bert> AE: Quite a few test cases for this.
209. # [02:15] <johnjan> actual issue: http://lists.w3.org/Archives/Public/www-style/2011Jan/0085.html
210. # [02:16] <Bert> [Mumble mumble]
211. # [02:16] <Bert> RESOLVED: No change for issue 268
212. # [02:17] <Bert> [DB and EE discuss some case]
213. # [02:18] * Quits: arno (arno@63.245.220.224) (Quit: Leaving.)
214. # [02:19] <Bert> EE: All impls seem to agree on what the first formatted line is.
215. # [02:19] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-269
216. # [02:19] <Bert> Topic: Issue 169
217. # [02:19] <Bert> s/169/269/
218. # [02:20] * Joins: arno (arno@63.245.220.224)
219. # [02:21] <Bert> EE: propose to change to edges of line box, instead of block.
220. # [02:21] <Bert> RESOLVED: Use line box edges instea dof block edges in issue 269
221. # [02:22] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-270
222. # [02:22] <Bert> Topic: Issue 270
223. # [02:23] <Bert> EE: I can propose a text.
224. # [02:23] <Bert> DB: I might have some issues. I started implementing this.
225. # [02:23] * Joins: arno1 (arno@192.150.10.200)
226. # [02:24] <Bert> RESOLVED: No change for issue 270. Do something in level 3.
227. # [02:24] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-271
228. # [02:24] <Bert> Topic: Issue 271
229. # [02:25] * Quits: arno (arno@63.245.220.224) (Ping timeout)
230. # [02:26] <Bert> AE: I think the colon in the spec was intended to mean "e.g."
231. # [02:26] <Bert> [Discussion about what issues to discuss. Skip all editorial?]
232. # [02:26] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Dec/0312.html
233. # [02:27] <fantasai> Anton's list of substantive issues ^
234. # [02:28] <dbaron> DB: Turn the email into a wiki page so we can start dealing with it
235. # [02:29] <fantasai> http://wiki.csswg.org/spec/css2.1/anton-lc-2010
236. # [02:29] <Bert> PL: What can we discuss now?
237. # [02:30] <Bert> ... How dow we go through Anton's list?
238. # [02:30] <Bert> AE: I have made comments on many of the issues.
239. # [02:31] <Bert> ... Most of them I found need no change.
240. # [02:32] <johnjan> so Arron and Elika will get Anton's email into actionable issues
241. # [02:32] <Bert> Topic: Test failures
242. # [02:32] <johnjan> discuss on wednesday.
243. # [02:33] <Bert> PL: Background-fixed 4 and 5 were expecting a fix in Gecko.
244. # [02:33] <Bert> DB: Give me 5 seconds...
245. # [02:34] <Bert> SF: Last week we suggested to leave it undefined.
246. # [02:35] <Bert> PL: I agree with undefined. Unless we have a proposal for a spec chnage.
247. # [02:35] <Bert> DB: Gecko might take a month to fix.
248. # [02:36] <Bert> EE: bg-pos may apply to image with no intrinsic size.
249. # [02:37] <Bert> AE: Is it not already undefined?
250. # [02:37] <Bert> DB: Might want to make it explicit, and say there is another spec that defines it.
251. # [02:37] <fantasai> The background position of background images with an intrinsic ratio and no intrinsic size is undefined in CSS2.1, see CSS3 Backgrounds and Borders.
252. # [02:38] <Bert> RESOLVED: Change bg-pos of images as fantasai just wrote.
253. # [02:39] <Bert> DB: So the test still needs fixing?
254. # [02:39] <Bert> Topic: test bidi-breaking-2
255. # [02:40] <dbaron> EE: should be a may
256. # [02:41] <dbaron> http://test.csswg.org/suites/css2.1/latest/xhtml1/block-in-inline-relpos-002.xht
257. # [02:41] <Bert> Topic: block-in-inline-relpos-002
258. # [02:42] <Bert> PL: What do we do with this one?
259. # [02:44] <Bert> [DB trying to find out why various browsers fail.]
260. # [02:44] <fantasai> arronei: http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/bidi-breaking-002.xht
261. # [02:44] <Bert> DB: Related to what we discussed earlier, about relative pos. affecting nested block elements.
262. # [02:45] <Bert> ... Four browsers that all do different things.
263. # [02:45] * Joins: myakura (d2e8220d@64.62.228.82)
264. # [02:46] <Bert> [DB and PL notice that two versions on diff. platforms of Opera do different things, too.]
265. # [02:47] <fantasai> bidi-breaking-002 should work now; removed the HTML <br> bit of the test (since that's up in the air anyway)
266. # [02:48] <Bert> [People looking over other people's shoulders to see what various browsers do on different platforms...]
267. # [02:48] <Bert> DB: Somebody should take an action to figure out what to do. And not me.
268. # [02:48] <Bert> AE: I can do it.
269. # [02:49] <Bert> ACTION Arron: propose a solution for block-in-inline-relpos-002
270. # [02:49] * trackbot noticed an ACTION. Trying to create it.
271. # [02:49] * RRSAgent records action 3
272. # [02:49] <trackbot> Created ACTION-311 - Propose a solution for block-in-inline-relpos-002 [on Arron Eicholz - due 2011-03-15].
273. # [02:53] <howcome> content-computed-value-001
274. # [02:54] <Bert> Topic: content-computed-value-001
275. # [02:54] <Bert> RESOLVED: Remove the test
276. # [02:55] * Parts: stearns (c0961605@78.129.202.38)
277. # [02:56] <Bert> Topic: replaced-intrinsic-ration-001
278. # [02:56] <smfr> we're going through the blocking tests on http://wiki.csswg.org/test/css2.1/blocking
279. # [02:56] <Bert> s/ration/ratio/
280. # [02:57] <dbaron> DB: Close to a patch for Gecko, just need to fix a few more existing tests.
281. # [02:58] <Bert> PL: It seems to be testing multiple things.
282. # [02:58] <Bert> EE: [something]
283. # [02:58] <Bert> PL: Are you going to define behavior?
284. # [02:58] <Bert> EE: I might want to fix this.
285. # [02:59] <Bert> ... I will propose text.
286. # [02:59] <Bert> ... For the spec.
287. # [03:00] <Bert> HL: Is this an SVG issue?
288. # [03:01] <fantasai> EE: Yes, affects all SVG that doesn't have a fixed size (i.e. scalable SVG)
289. # [03:01] <Bert> RESOLVED: Change the spec in some way.
290. # [03:01] <fantasai> EE: Proposal is to make sizing of replaced elements with intrinsic ratio but no size undefined.
291. # [03:04] <Bert> RESOLVED: ... and put the current rule in level 3 instead.
292. # [03:04] <Bert> BB: It was put in on request from SVG wasn't it?
293. # [03:05] <Bert> Topic: uri-016
294. # [03:05] <johnjan> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/uri-016.htm
295. # [03:05] <fantasai> no, it was put in a long time ago because it was it wasn't defined
296. # [03:06] <fantasai> the test is failing because UAs misinterpreted SVG
297. # [03:07] * Joins: kennyluck (kennyluck@128.30.52.169)
298. # [03:08] <Bert> PL: We don't have the exit criteria from other CSS modules in the CSS 2.1 spec,
299. # [03:08] <Bert> ... Difference is about experimental builds.
300. # [03:08] <Bert> ... Didn't we resolve to fix that already?
301. # [03:09] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-272
302. # [03:09] <Bert> RESOLVED: Update CSS 2.1 exit criteria to the current (CSS3 standard) exit criteria, minus the 30-day implementation requirement.
303. # [03:10] * Quits: glazou (glazou@63.245.220.224) (Quit: glazou)
304. # [03:11] <Bert> [End of meeting for today]
305. # [03:12] * Quits: shonda (shonda@63.245.220.224) (Quit: Leaving...)
306. # [03:13] * Quits: sgalineau (sylvaing@63.245.220.224) (Quit: sgalineau)
307. # [03:13] * Quits: Arron (arronei@63.245.220.224) (Ping timeout)
308. # [03:13] * Quits: jdaggett (jdaggett@63.245.220.224) (Quit: jdaggett)
309. # [03:14] <Bert> rrsagent, draft minutes
310. # [03:14] <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert
311. # [03:14] <Bert> rrsagent, make logs public
312. # [03:14] <RRSAgent> I have made the request, Bert
313. # [03:15] * Quits: howcome (howcome@63.245.220.224) (Ping timeout)
314. # [03:15] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
315. # [03:16] * Quits: shan (qw3birc@128.30.52.28) (Quit: Page closed)
316. # [03:16] * Quits: mihara (mi@63.245.220.224) (Quit: Leaving)
317. # [03:17] * Quits: smfr (smfr@63.245.220.224) (Quit: smfr)
318. # [03:17] <Bert> Hmm, forgot to tell rrsagent that the meeting spanned midnight. :-(
319. # [03:18] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
320. # [03:20] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
321. # [03:23] * Quits: TabAtkins_ (tabatkins@63.245.220.224) (Ping timeout)
322. # [03:25] * Quits: tantek (tantek@63.245.220.240) (Quit: tantek)
323. # [03:26] * Quits: szilles (chatzilla@63.245.220.224) (Ping timeout)
324. # [03:27] * Quits: plinss_ (plinss@63.245.220.224) (Quit: plinss_)
325. # [03:38] * Quits: arno1 (arno@192.150.10.200) (Ping timeout)
326. # [03:44] * Quits: myakura (d2e8220d@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
327. # [03:45] * Quits: dbaron (dbaron@63.245.220.240) (Ping timeout)
328. # [03:48] * Quits: dsinger (dsinger@17.73.146.150) (Ping timeout)
329. # [03:59] * Joins: miketaylr (miketaylr@76.15.238.5)
330. # [04:26] * Joins: bradk (bradk@99.7.175.117)
331. # [04:35] * Quits: bradk (bradk@99.7.175.117) (Quit: Computer has gone to sleep)
332. # [04:38] * Joins: bradk (bradk@99.7.175.117)
333. # [04:46] * Quits: bradk (bradk@99.7.175.117) (Quit: Computer has gone to sleep)
334. # [04:46] * Quits: Xaxio (Xaxio@75.28.47.214) (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/)
335. # [04:55] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
336. # [04:58] * Joins: Xaxio (Xaxio@75.28.47.214)
337. # [05:59] * Joins: tantek (tantek@69.181.124.60)
338. # [06:04] * Joins: fantasai2 (yaaic@208.54.5.58)
339. # [06:07] * Quits: homata (homata@58.158.182.50) (Ping timeout)
340. # [06:08] * Quits: fantasai2 (yaaic@208.54.5.58) (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org)
341. # [06:08] * Joins: homata (homata@58.158.182.50)
342. # [06:16] * Quits: miketaylr (miketaylr@76.15.238.5) (Quit: miketaylr)
343. # [06:56] * Quits: tantek (tantek@69.181.124.60) (Quit: tantek)
344. # [07:05] * Joins: dsinger (dsinger@17.73.145.98)
345. # [07:11] * Joins: jdaggett (jdaggett@70.36.214.37)
346. # [07:11] * Quits: jdaggett (jdaggett@70.36.214.37) (Quit: jdaggett)
347. # [07:23] * Joins: Arron (arronei@209.118.182.194)
348. # [07:25] * Joins: sylvaing (sylvaing@209.118.182.194)
349. # [07:43] * Joins: plinss_ (plinss@72.254.57.83)
350. # [07:45] * Joins: anne (annevk@83.85.115.123)
351. # [07:49] * Joins: dbaron (dbaron@173.228.28.143)
352. # [07:52] * Joins: arno (arno@208.87.61.227)
353. # [07:55] * Quits: sylvaing (sylvaing@209.118.182.194) (Quit: sylvaing)
354. # [08:01] * Quits: dbaron (dbaron@173.228.28.143) (Ping timeout)
355. # [08:08] * Joins: homata__ (homata@58.158.182.50)
356. # [08:08] * Joins: TabAtkins_ (tabatkins@76.253.3.102)
357. # [08:10] * Quits: homata (homata@58.158.182.50) (Ping timeout)
358. # [08:24] * Joins: arno1 (arno@192.150.10.200)
359. # [08:24] * Quits: plinss_ (plinss@72.254.57.83) (Ping timeout)
360. # [08:25] * Quits: arno (arno@208.87.61.227) (Ping timeout)
361. # [08:37] * Joins: plinss_ (plinss@72.254.57.83)
362. # [08:42] * Joins: Martijnc (Martijnc@91.176.79.35)
363. # [08:43] * Quits: TabAtkins_ (tabatkins@76.253.3.102) (Ping timeout)
364. # [09:02] * Joins: homata (homata@58.158.182.50)
365. # [09:04] * Quits: homata__ (homata@58.158.182.50) (Ping timeout)
366. # [09:04] * Quits: plinss_ (plinss@72.254.57.83) (Ping timeout)
367. # [09:11] * Joins: plinss_ (plinss@72.254.57.83)
368. # [09:33] * Quits: plinss_ (plinss@72.254.57.83) (Ping timeout)
369. # [09:42] * Joins: homata__ (homata@58.158.182.50)
370. # [09:43] * Quits: homata (homata@58.158.182.50) (Ping timeout)
371. # [10:08] * Quits: arno1 (arno@192.150.10.200) (Ping timeout)
372. # [10:35] * Quits: Arron (arronei@209.118.182.194) (Ping timeout)
373. # [10:49] * Joins: plinss_ (plinss@72.254.57.83)
374. # [10:50] * Joins: Ms2ger (Ms2ger@91.181.118.178)
375. # [10:55] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
376. # [10:56] * Joins: lhnz (lhnz@188.223.83.48)
377. # [11:23] * Quits: plinss_ (plinss@72.254.57.83) (Ping timeout)
378. # [11:31] * Joins: plinss_ (plinss@72.254.57.83)
379. # [11:43] * Quits: plinss_ (plinss@72.254.57.83) (Ping timeout)
380. # [11:51] * Joins: homata (homata@58.158.182.50)
381. # [11:51] * Joins: plinss_ (plinss@72.254.57.83)
382. # [11:53] * Quits: homata__ (homata@58.158.182.50) (Ping timeout)
383. # [12:01] * Quits: arronei (arronei@131.107.0.118) (Ping timeout)
384. # [12:07] * Joins: arronei (arronei@131.107.0.87)
385. # [12:17] * Quits: Martijnc (Martijnc@91.176.79.35) (Connection reset by peer)
386. # [12:24] * Joins: Martijnc (Martijnc@91.176.100.249)
387. # [12:47] * Quits: plinss_ (plinss@72.254.57.83) (Quit: plinss_)
388. # [13:47] * Quits: davve (davve@83.218.67.122) (Client exited)
389. # [14:31] * RRSAgent excuses himself; his presence no longer seems to be needed
390. # [14:31] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
391. # [14:57] * Joins: miketaylr (miketaylr@206.217.92.186)
392. # [15:53] * Joins: arno (arno@208.87.61.227)
393. # [15:59] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
394. # [16:00] * Joins: lhnz (lhnz@188.223.83.48)
395. # [16:04] * Quits: arno (arno@208.87.61.227) (Quit: Leaving.)
396. # [16:08] * Joins: bradk (bradk@99.7.175.117)
397. # [16:13] * Joins: dbaron (dbaron@173.228.28.143)
398. # [16:19] * Joins: plinss_ (plinss@72.254.101.200)
399. # [16:19] * Quits: plinss_ (plinss@72.254.101.200) (Quit: plinss_)
400. # [16:20] * Joins: myakura (myakura@123.224.162.182)
401. # [16:23] * Joins: kennyluck (kennyluck@128.30.52.169)
402. # [16:23] * Joins: plinss_ (plinss@72.254.101.200)
403. # [16:28] * Joins: Arron (arronei@209.118.182.194)
404. # [16:28] * Quits: karl (karlcow@128.30.54.58) (Client exited)
405. # [16:30] * Quits: bradk (bradk@99.7.175.117) (Ping timeout)
406. # [16:34] * Quits: Arron (arronei@209.118.182.194) (Ping timeout)
407. # [16:35] * Quits: plinss_ (plinss@72.254.101.200) (Quit: plinss_)
408. # [17:13] * Quits: dsinger (dsinger@17.73.145.98) (Client exited)
409. # [17:26] * Quits: Martijnc (Martijnc@91.176.100.249) (Quit: Martijnc)
410. # [17:28] * Joins: Martijnc (Martijnc@91.176.100.249)
411. # [17:29] * Joins: Martijnc_ (Martijnc@91.176.100.249)
412. # [17:29] * Quits: Martijnc (Martijnc@91.176.100.249) (Connection reset by peer)
413. # [17:29] * Quits: dbaron (dbaron@173.228.28.143) (Ping timeout)
414. # [17:29] * Martijnc_ is now known as Martijnc
415. # [17:44] * Joins: szilles (chatzilla@63.245.220.224)
416. # [17:55] * Joins: dsinger (dsinger@17.72.147.117)
417. # [17:56] * Joins: arno (arno@63.245.220.224)
418. # [17:57] * Joins: plinss_ (plinss@63.245.220.224)
419. # [17:59] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
420. # [17:59] <RRSAgent> logging to http://www.w3.org/2011/03/08-css-irc
421. # [17:59] <plinss_> invite zakim, #css
422. # [18:00] * Joins: Zakim (rrs-bridgg@128.30.52.169)
423. # [18:01] * Joins: stearns (c0961605@207.192.75.252)
424. # [18:02] * Quits: myakura (myakura@123.224.162.182) (Client exited)
425. # [18:04] * Joins: sylvaing (sylvaing@63.245.220.224)
426. # [18:06] * Joins: TabAtkins_ (tabatkins@208.54.5.66)
427. # [18:06] * Joins: glazou (glazou@63.245.220.224)
428. # [18:06] * Joins: mihara (mihara@63.245.220.224)
429. # [18:07] * Joins: shan (qw3birc@128.30.52.28)
430. # [18:07] * Joins: johnjan (qw3birc@128.30.52.28)
431. # [18:07] <fantasai> ScribeNick: fantasai
432. # [18:07] * Joins: Arron (arronei@63.245.220.224)
433. # [18:07] <fantasai> Topic: Agenda
434. # [18:08] <fantasai> Steve: Request toput tokyo workshop dates today
435. # [18:08] * Quits: Arron (arronei@63.245.220.224) (Quit: Arron)
436. # [18:08] <fantasai> ?: multicol today
437. # [18:08] * Joins: Arron (arronei@63.245.220.224)
438. # [18:09] <fantasai> glazou: module template tomorrow
439. # [18:09] * Quits: TabAtkins_ (tabatkins@208.54.5.66) (Ping timeout)
440. # [18:09] * Joins: dbaron (dbaron@63.245.220.240)
441. # [18:09] <fantasai> glazou: pull tokyo dates and multicol for today, keep rest for tomorrow
442. # [18:09] <fantasai> glazou: Start with Adobe's proposal
443. # [18:10] <fantasai> Topic: Adobe's Template Proposal
444. # [18:10] <plinss_> s/Template/Regions/
445. # [18:10] * Joins: howcome (howcome@63.245.220.224)
446. # [18:11] * Joins: smfr (smfr@63.245.220.224)
447. # [18:11] <fantasai> Arno: I'd like tot talk to you a little bit about things we work on we're calling CSS "Regions"
448. # [18:11] <fantasai> arno: Would like your feedback on whether it's interesting, going in an interesting direction, etc.
449. # [18:11] * Joins: bradk (bradk@63.245.220.224)
450. # [18:12] <fantasai> arno: It started by us talking to our customers, especially print customers using InDesign t do fancy layouts
451. # [18:12] <fantasai> arno: e.g. Conde Nast
452. # [18:12] <fantasai> arno: They want to bring the experience ppl have on paper into digital media
453. # [18:12] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
454. # [18:12] <fantasai> arno: We started experimenting, and some of those magazines are already available on the iPad
455. # [18:12] <fantasai> arno: We very quickly ran into some limitations
456. # [18:13] <fantasai> arno: e.g. Wired has very complex layouts
457. # [18:13] <fantasai> arno: We tried using various technologies to represent those layouts
458. # [18:13] <fantasai> arno: But in this version we had to use images to represent each page
459. # [18:13] <fantasai> arno: It's a lot of work, since the designers have to do layouts twice once for layout and portrait
460. # [18:13] <fantasai> arno: With different device aspect ratios, it's even more work
461. # [18:14] <fantasai> arno: Not a good solution
462. # [18:14] <fantasai> arno: Not the case for everyone -- some customers have very simple layouts, close to templates, can use HTML to represent their ocntent
463. # [18:14] <fantasai> arno: which has lots of benefits
464. # [18:14] <fantasai> arno: We want to find the way to bridge the gap between HTML layouts you can do today, and what you can do on paper
465. # [18:14] <fantasai> arno: You have very sophisticated layout of text, interaction of graphics and text
466. # [18:15] <fantasai> arno shows pages with text flowing around contoured images, fitted to shaped regions
467. # [18:15] <fantasai> arno: We want to be able to find ways to represent these sophisticated layouts in HTML and CSS
468. # [18:15] <fantasai> arno: We studied these and came up with a proposal tha we think solves the problems.
469. # [18:15] <fantasai> arno: We wanted to make sure what we were thinking about was implementable
470. # [18:16] <fantasai> arno: So we started investigating implementing it
471. # [18:16] <fantasai> arno: BTw, another use case is of course printing, which would benefit from sophisticated layouts
472. # [18:16] <fantasai> arno: We started experimenting with WebKit
473. # [18:16] <fantasai> arno: I'm going to show you some screenshots of some things, and then also live demos
474. # [18:16] <fantasai> arno: Starting with very simple and basic things, it's columns
475. # [18:17] <fantasai> arno shows a 3-col layout
476. # [18:17] <fantasai> arno: You can do this with multicol
477. # [18:17] <fantasai> arno: You have some fairly simple markup -- three divs and a heading
478. # [18:17] <fantasai> divs are labeled region1 through 3
479. # [18:18] <fantasai> prior to that there's another div called article-content, which includes a heading and then the flow content (paragraphs)
480. # [18:18] <fantasai> the regions are styled to be boxes floating side by side
481. # [18:19] <fantasai> article-content is assigned a flow-thread: main;
482. # [18:19] <fantasai> the region3 divs are assigned display: region; region-thread: main;
483. # [18:20] <fantasai> howcome: Those region elements are only there to give the layout
484. # [18:20] <fantasai> Simon: What happens to the content of the region elements?
485. # [18:20] * Joins: mollydotcom (mollyh@173.164.174.193)
486. # [18:20] <fantasai> jdaggett: It would be better to not put the layout structure as markup in the document.
487. # [18:21] <fantasai> arno: Next example, we add an image sitting on top of the two first columns
488. # [18:21] <fantasai> arno: You adjust the two columns to shorten them, and then place the image
489. # [18:21] <fantasai> glazou: You cannot make content flow from one region to another, right?
490. # [18:21] <fantasai> arno: correct
491. # [18:21] * fantasai is confused about that
492. # [18:22] <fantasai> jdaggett: I'm wondering if you looked at some of the other proposals..
493. # [18:22] <fantasai> plinss: This is not the interesting case. This is a very basic case.
494. # [18:22] * Joins: TabAtkins_ (tabatkins@63.245.220.224)
495. # [18:22] * Ms2ger is concerned about the number of layout specs
496. # [18:22] <fantasai> jdaggett: But I think this is added semantics on top of one of the other layout approaches
497. # [18:23] <fantasai> arno: One of the things you can do is to specify the order in which content flows
498. # [18:23] <fantasai> arno: you do this by specifying region-index: <integer> on the region elements
499. # [18:23] <fantasai> arno: Since the divs are just divs, you can also do more sophisticated things like applying transforms.
500. # [18:23] <fantasai> arno: Another thing we've been talking about are exclusions
501. # [18:24] <fantasai> arno: Which is saying "I want the text to avoid these areas"
502. # [18:24] <fantasai> arno: So you can have images that encroach on the text
503. # [18:25] <fantasai> arno: Our proposal is to use an exclusion-shape property that takes coordinates which you apply to an element, and then assign exclusions: "#idofelement" to the flow content
504. # [18:25] <dbaron> ...could also use alpha area of image
505. # [18:25] <fantasai> jdaggett: SVG path or mask would make more sense
506. # [18:25] <fantasai> http://www.w3.org/blog/CSS/2007/07/03/rotations_and_non_rectangular_floats
507. # [18:26] <dbaron> fantasai: There was a proposal from Bert for doing this by adding a single keyword to float.
508. # [18:26] <dbaron> arno: also want to specify geometric shapes even if there's no image
509. # [18:26] <fantasai> arno: You also want to do this for e.g. a circular pull-quote
510. # [18:27] <Bert> (For the old, 1996(!) idea for flow around non-rectangular images: see 'contour' in https://www.w3.org/Style/Group/css3-src/css3-box/Overview.html#the-float-property)
511. # [18:27] <Bert> (For an idea for non-rectangular/connected regions: https://www.w3.org/Style/Group/css3-src/css3-layout/Overview.html#chaining-slots-the-chains-property)
512. # [18:28] <dbaron> [discussion of margin around the alpha shape]
513. # [18:28] <Bert> (The "margin" around non-rect images in the contour idea is given by areas that are almost transparent, say 99%)
514. # [18:28] <howcome> http://www.w3.org/TR/WD-layout
515. # [18:29] <fantasai> arno: we just started with the coordinates since that was simple to implement and could do everything
516. # [18:29] <fantasai> discussion of float intrusions that break a line in half
517. # [18:30] <fantasai> plinss: We have a convention, starting with clip property, of using functional notation with shape e.g. rect(...)
518. # [18:30] <fantasai> plinss: That would let you have different shapes
519. # [18:30] <fantasai> plinss: more easily
520. # [18:30] <fantasai> plinss: The other thing is you have a property linking from one to the other
521. # [18:30] <fantasai> plinss: to define the exclusion
522. # [18:31] <fantasai> plinss: What is the coordinates relative to?
523. # [18:31] <fantasai> alex: What defines the tightwrap, content wnats to tightwrap, or shape wants everything to wrap around it?
524. # [18:31] <fantasai> alex: In CSS1, it was float requesting wrapping
525. # [18:32] <fantasai> alex: So you could have a boolean, wrap around stuff, or don't wrap around stuff.
526. # [18:33] <fantasai> alex: if you want to control, e.g. this bfc doesn't avoid floats, or this non-bfc avoids floats
527. # [18:33] <fantasai> discussion of bfcs
528. # [18:34] <fantasai> Steve: Think of the part that intrudes as being part of the bfc
529. # [18:34] <fantasai> dbaron: Well, if we have a BFC due to scrolling, you don't want any floating content intruding into that content and forcing relayout on scroll
530. # [18:34] * Joins: hyatt (hyatt@98.200.13.42)
531. # [18:35] <fantasai> alex: But that's a special case. overflow: hidden; it's totally reasonable to wrap around
532. # [18:35] <fantasai> arno show s an example of columned text flowing around the coyote
533. # [18:35] <fantasai> arno shows a page layout that uses this as a component
534. # [18:36] <fantasai> arno pulls up a live demon
535. # [18:36] <fantasai> arno: Here's the example with columns that have been transformed to be crooked
536. # [18:37] <fantasai> arno edits the contenteditable content: the content flows from one column to the other
537. # [18:37] <fantasai> plinss: What about property inheritance?
538. # [18:37] <fantasai> plinss: Does content flowing into a region inherit from the region or its element tree parent?
539. # [18:38] <fantasai> Steve: There is a desire to allow inheritance from regions (in its equivalent model)
540. # [18:38] <fantasai> Steve: We have a special function, like inherit-from-region, that does that
541. # [18:38] <fantasai> Steve: What's there doesn't quite match CSS's model
542. # [18:39] <fantasai> plinss: I looked at that and couldn't figure out how it works
543. # [18:39] <fantasai> Steve: This would be similar to the way ::first-line works
544. # [18:40] <fantasai> fantasai: If you're doing inheritable properties, you'll probably want selectors too. So you can change not just the color of the text overall, but e.g. links inside the region
545. # [18:40] <fantasai> fantasai: If you go down this route, people will want to go in that direction
546. # [18:41] <fantasai> ...
547. # [18:41] <fantasai> howcome: Have you shipped content with this?
548. # [18:41] <fantasai> arno: No, just experimental
549. # [18:42] <fantasai> howcome asks about resizing and reflow
550. # [18:42] <fantasai> howcome: With multicol, you'd add a third column as the page gets wider
551. # [18:42] <fantasai> howcome: what would you do here? is it tied only to two columns?
552. # [18:43] <fantasai> Steve: This is with fixed regions, each explicitly specified.
553. # [18:43] <fantasai> Steve: It needs to be adapted to work with multicol, flexbox, grid layout, etc.
554. # [18:43] <fantasai> Steve: The key concept is the threads
555. # [18:43] <fantasai> Steve: and the concept of exclusions
556. # [18:43] * Parts: mollydotcom (mollyh@173.164.174.193)
557. # [18:44] <fantasai> jdaggett: So what you're saying is not the syntax that's important, but those two concepts that are important.
558. # [18:44] <fantasai> Steve: Yes. There's still some work to do to make this fit into CSS well
559. # [18:44] <fantasai> plinss: Another issue is that you're using 'display' to make something a region. You should use something else, so that we can control display of the regions
560. # [18:45] <dbaron> maybe the 'content' property would work?
561. # [18:45] <dbaron> e.g., content: flow(main), or content: flow(main, 2) to give indices
562. # [18:46] <fantasai> plinss: In most cases, you want to use the other layout systems you have, and just have content flow differently through it
563. # [18:46] <fantasai> Phil: What happens if you run out of content?
564. # [18:46] <fantasai> (or too much)
565. # [18:46] <fantasai> arno: It's a good question.
566. # [18:47] <fantasai> fantasai: The other thing is that the regions shouldn't be empty elements in the document, they should be separate. SO you odn't have to build the layout into the document content
567. # [18:48] <fantasai> Bert: César and I worked on some of this flow threading with his studies on the Template module
568. # [18:48] <hyatt> extend the slot concept from css3 template layout to allow for the specification of positioned slots
569. # [18:48] <fantasai> Bert: One thing that became clear was that you need a baseline grid, so that the lines are consistently placed
570. # [18:49] <dbaron> ...so that if you have two regions above each other (with different horizontal positions), you don't have a gap due to having half a line at the bottom of the first
571. # [18:49] <stearns> need a baseline grid for content today (even if it's not all part of the same flow)
572. # [18:49] <fantasai> Bert: Other comment, when you were moving the image in the demo, you have some cases where the content shows up in holes in the image. In howcome's proposal, the content always had to be on the outside
573. # [18:49] <fantasai> Bert: So you wouldn't split the content into two columns
574. # [18:52] <fantasai> glazou: You want to be able to flow text inside, e.g. a bowl
575. # [18:52] <fantasai> fantasai: You're talking about two different things.
576. # [18:52] <fantasai> glazou clarifies by drawing a picture
577. # [18:53] <fantasai> 11|222|33
578. # [18:53] * Joins: jdaggett (jdaggett@63.245.220.224)
579. # [18:53] <fantasai> 44\555/66
580. # [18:53] <fantasai> 77---88
581. # [18:53] <fantasai> arno's example doesn't actually allow a line to be split by the float
582. # [18:54] <fantasai> but it does allow the image to define the contour on both the left and right side of the line, if it's bowl-shaped
583. # [18:54] <Bert> (Example XXII in https://www.w3.org/Style/Group/css3-src/css3-layout/Overview.html#chaining-slots-the-chains-property defines a reading order over partly side-by-side regions)
584. # [18:54] <fantasai> glazou's example intrudes into the text splitting the line into multiple pieces
585. # [18:54] * fantasai thinks Bert should put that on dev.w3.org
586. # [18:54] <fantasai> howcome: So what happens today if you have too much content for the regions?
587. # [18:54] <fantasai> arno: It will not display
588. # [18:55] * Ms2ger agrees with fantasai
589. # [18:55] <fantasai> smfr: What if you put overflow: scroll on the last region?
590. # [18:55] <fantasai> Tab: Could think of this as a kind of overflow mode
591. # [18:55] <hyatt> css3 template layout defines a grid of anonymous slots. you could imagine also allowing it to define anonymous positioned slots (that other content could then flow around/avoid)
592. # [18:55] <fantasai> Tab: Would clarify what overflow: scroll means on the first region -- nothing
593. # [18:56] * fantasai reads hyatts comments aloud
594. # [18:57] <dbaron> peterl: (responding to hyatt's first comment) I'd actually like to see the other way - this replacing template's slot concept.
595. # [18:57] <TabAtkins_> >
596. # [18:57] <hyatt> div { positioned-slots: sidebar, masthead, body; } ::slot(sidebar) { position: absolute; left:100px; top:100px; box-shape: <some path>; }
597. # [18:57] <fantasai> howcome: We need to make sure this wokrs in a reusable way for longer articles, for printing
598. # [18:58] <hyatt> css3 template layout supports per-page templates too
599. # [18:58] <fantasai> Bert talks about his attempt to extend slots concept in template-layout
600. # [18:58] <dbaron> peterl: I'd like to be able to define regions in an @page rule.
601. # [18:59] <Bert> (Extend in the sense of automatic repeating the same layout template if there is more room, without need for media queries.)
602. # [18:59] * Joins: alexmog (qw3birc@128.30.52.28)
603. # [19:00] <hyatt> i would try to separate out all the concepts here. there is (1) content flowing across linked regions, (2) the ability to define an irregular external shape that content flows around, (3) the ability do specify an irregular shape that content inside fits to, and (4) the definition of placed regions themselves that content can flow around
604. # [19:00] <fantasai> glazou: Do you want to standardize this in CSSWG?
605. # [19:00] <fantasai> arno: If you're interested in this, yes.
606. # [19:01] <fantasai> jdaggett: Before we get to the stage of these guys spending time putting together a proposal
607. # [19:01] <fantasai> jdaggett: I think it would make more sense for your group to start by reviewing the modules we already have, and see what you would need to /change/ to make them work for you
608. # [19:01] <fantasai> jdaggett: The cases you're trying to solve are valid, but the syntax you're doing is grotty
609. # [19:02] * Joins: shonda (shonda@63.245.220.224)
610. # [19:02] <fantasai> smfr: I agree, we should avoid adding another module and try to work this into e.g. Template Layout
611. # [19:02] <stearns> linked regions might make sense in Template, but would exclusions?
612. # [19:02] * fantasai thinks we need a Floats module
613. # [19:03] <fantasai> howcome: We can't keep adding more and more advanced layout systems. We should try to merge them
614. # [19:03] * Joins: tantek (tantek@63.245.220.240)
615. # [19:03] <fantasai> Steve: There are several key concepts here. One is the threading concept, which would fit well in many of our layout specs
616. # [19:03] <hyatt> the concept of content flowing around a positioned shape and/or of irregular shapes is just new properties for positioned or floating elements (depending on what approach you decide to take)
617. # [19:04] <fantasai> Steve: The other key piece is the exclusion piece, which is separate but also important
618. # [19:04] <hyatt> the concept of flow across containers should IMO be limited to anonymous models (multicol, template layout)
619. # [19:05] <fantasai> dbaron: We could use 'content' property to assign content to a flow, e.g. with a flow() function
620. # [19:05] <hyatt> i think just using positioned elements as the way to flow around content instead of floats, and then use positioned element z-index rules to say whether you avoid or not might work fine
621. # [19:05] <fantasai> Steve: That's a pull model, this is a push model.
622. # [19:05] <hyatt> e.g,. establish a stacking context, then your internal stuff doesn't propagate out
623. # [19:05] <hyatt> auto z-inxex it does, etc.
624. # [19:05] <fantasai> Steve: The third approach is to define a mapping between the twol.
625. # [19:05] <fantasai> Steve: Those are 3 different ways of looking at the problem.
626. # [19:05] <fantasai> Steve: Layout and grid are using a push model.
627. # [19:05] <fantasai> Steve: I agree you could use a pull model as well
628. # [19:06] <fantasai> Bert: There's a pull model in the cross-references in GCPM
629. # [19:06] <fantasai> q+
630. # [19:06] * Zakim sees fantasai on the speaker queue
631. # [19:06] <fantasai> Bert explains hyatt's comment above
632. # [19:07] <fantasai> Bert: wrt #3, I was wondering if that should be extended to also make the text exactly fit a certain shape by e.g. making it smaller or larger
633. # [19:09] <fantasai> Steve: That was in the proposal, too, arno just didn't mention it
634. # [19:09] <fantasai> Tab likes hyatt's comments
635. # [19:09] <fantasai> and strongly agrees with using anonymous boxes instead of real elements to define the regions
636. # [19:10] <fantasai> Steve: Classic example of pushing content into an external region that only shows up when needed is footnotes.
637. # [19:10] <fantasai> Tab: You can tell the region to only exist if it has content inside of it.
638. # [19:11] <fantasai> glazou: Another way of specifying exclusions, used many years ago, is like background image
639. # [19:11] <fantasai> glazou: You position the image and it defines an exclusion
640. # [19:11] <fantasai> Tab says something that I didn't quite follow....
641. # [19:12] <hyatt> @page { positioned-slots: header, sidebar, body(col1, col2) ::slot(col1) { ... } ::slot(col2) { ... } } You could imagine the "chains" linking being done without a property, e.g., in the specification of the template itself... see body(col1, col2) example
642. # [19:12] <fantasai> ...
643. # [19:12] <fantasai> Steve: In a gridlike or template-like layout you'd like to position to cell boundaries in that model, which doesn't quite fit into the bgpos model.
644. # [19:13] <fantasai> glazou: Desktop publishing software can do that. What is the best option in terms of you for CSS to be able to translate those layouts into CSS layouts and vice versa?
645. # [19:13] <fantasai> glazou: If we run into that, people are going to base layouts in CSS, so it needs to be compatible with desktop software
646. # [19:14] <fantasai> Steve: FYI, glazou writs an editor
647. # [19:14] <fantasai> glazou: Need to allow round-tripping
648. # [19:14] <fantasai> arno: For us the key thing is to have the expressiveness. We are willing to take the cost on the tooling side.
649. # [19:14] <fantasai> arno: round-tripping is a good point to bring up, though
650. # [19:14] <TabAtkins_> Tab: The only problem with defining exclusions purely on the content element is that it may then be difficult to position content that should sit in those exclusions (like a callout) in an appropriate manner. But Positioned Layout, which I'll work on later this year, should be able to solve this - you can abspos an element relative to the content element, and specify the exclusion and callout using nearly identical rules as a bg-position and as top/right
651. # [19:15] <fantasai> arno: want for an author to be able to us the tools, but more importantly the concepts they are used to
652. # [19:15] * Quits: arno (arno@63.245.220.224) (Quit: Leaving.)
653. # [19:16] <glazou> all applause Arno's pres and demo
654. # [19:16] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
655. # [19:16] * Joins: arno (arno@63.245.220.224)
656. # [19:34] * Quits: mihara (mihara@63.245.220.224) (Ping timeout)
657. # [19:34] * Quits: glazou (glazou@63.245.220.224) (Quit: glazou)
658. # [19:34] * Joins: arno1 (arno@192.150.10.200)
659. # [19:35] * Joins: mihara (mihara@63.245.220.224)
660. # [19:36] * Quits: arno (arno@63.245.220.224) (Ping timeout)
661. # [19:37] <fantasai> alex: What we have here in this version of the spec, it tries to roll into it all the feedback we've had so far
662. # [19:37] <fantasai> if somalex: If something is thatere, doesn't necessarily mean we have the final overall picture
663. # [19:37] <fantasai> alex: We're trying to be inclusive here, we wanted to produce a version of how it might work with the feedback
664. # [19:37] <smfr> which spec? can we have a link?
665. # [19:37] <fantasai> alex: We're getting to the shape where we can think about how it integrates with other specs, e.g. merge with Template Layout
666. # [19:37] <fantasai> alexmog: If there something we didn't get here, doesn't make sense to have there, let's discuss
667. # [19:38] <fantasai> Markus: Our main goal was to address the feedback from the last F2F, align with Template Layout, figure out integration
668. # [19:38] <fantasai> Markus: Also think more about print layout and lines
669. # [19:39] <arno1> Thanks everyone for the great feedback!
670. # [19:40] <smfr> http://dev.w3.org/csswg/css3-grid-align/
671. # [19:40] <fantasai> Phil: Hi, my name is Phil and I'm from Microsoft, and I'm one of th editors on the CSS Grid specification
672. # [19:40] <fantasai> Phil: Recap of feedback was to think in lines, not just thinking in rows and columns
673. # [19:40] <fantasai> Phil: also think about naming lines to simplify maintenance so you don't have to renumber when you change things
674. # [19:41] <fantasai> Phil: We also thought about naming regions of space.
675. # [19:41] <fantasai> Phil: Template Layout does this, so we looked into incorporating that idea
676. # [19:41] <fantasai> Phil: Also thought about ::slot() pseudo and putting multiple elements into a slot
677. # [19:41] <fantasai> Phil: ... a default slot
678. # [19:42] <fantasai> Phil: I'll start by just walking through this and summarizing.
679. # [19:42] <fantasai> Phil: Grid is not a table. Can do things tables can't do, e.g. hav cells overlap
680. # [19:42] <fantasai> Phil: It's similar positioning in that regard; can be considered an alternate grid system for positioning
681. # [19:43] <fantasai> Phil: We think people will use grid to do page layouts, form layouts, etc.
682. # [19:43] <fantasai> Phil: We want layouts to be able to adapt to available space
683. # [19:43] <fantasai> Phil: So we have some concepts
684. # [19:44] <fantasai> Phil: auto sizing to the size of the content
685. # [19:44] <fantasai> Phil: min/max functions
686. # [19:44] <fantasai> Phil: fractional units, allocating remaining space
687. # [19:44] <fantasai> Phil: You declare a grid by setting its display to grid
688. # [19:44] <fantasai> Phil shows Example 1
689. # [19:45] <fantasai> Phil: Declare a grid with "display: grid", set grid columns and rows
690. # [19:45] <fantasai> position to grid
691. # [19:45] <fantasai> Phil moves to next section
692. # [19:46] <fantasai> Phil shows template layout in grid
693. # [19:46] <fantasai> Phil: assign into template regions with 'grid-cell' property
694. # [19:46] <fantasai> Phil: We're not using the position property here
695. # [19:47] <fantasai> Phil shows slider control example
696. # [19:47] <fantasai> Phil: In this example we're using an alternative syntax that names the grid lines
697. # [19:47] <fantasai> Phil: To name a grid line, you just specify a string before the measurement
698. # [19:48] <fantasai> Phil: You can assign starting and ending lines to an element to position it in the grid
699. # [19:49] <fantasai> Phil: There are tracks, lines, and cells in the grid model
700. # [19:49] <fantasai> Phil: Tracks are the columns and rows of the grids
701. # [19:49] <fantasai> Phil: grid-columns: 150px 1fr; creates two columns, a 150px column and a remaining space column
702. # [19:49] <fantasai> Phil: This gives us 3 lines
703. # [19:50] <fantasai> Phil: In old spec you would define cells implicitly by giving a span property, and then could align content within that cell (which could span multiple row-col intersections)
704. # [19:50] <fantasai> Phil: in new spec you can define those cells explicitly
705. # [19:51] <fantasai> ...
706. # [19:51] <fantasai> Phil: grid-cell speudo
707. # [19:51] <fantasai> Phil: In template module you would define of the grid-cell with the template string
708. # [19:52] * Joins: bradk (bradk@63.245.220.224)
709. # [19:52] <fantasai> Phil: Here you can create a grid-cell [somehow]
710. # [19:52] <fantasai> Phil: by using the grid-cell pseudo element, and giving it positions
711. # [19:52] * Quits: Martijnc (Martijnc@91.176.100.249) (Quit: Martijnc)
712. # [19:53] <fantasai> Phil: e.g. #grid::grid-cell("cell") { grid-column: .. ; grid-row: ...; }
713. # [19:54] <fantasai> Phil: This creates a named cell, that you can then assign into just like you can assing into template-created named cells
714. # [19:54] <fantasai> dbaron: maybe split this example using markup instead of a comment, it's not clear they are two different approaches to the same thing
715. # [19:55] <fantasai> Steve: So you wanted to create a cell on the grid-line strucutre using pseudo-element
716. # [19:56] <fantasai> sylvaing: That's similar to what hyatt proposed earlier, with the ::slot() syntax creating a flow target
717. # [19:56] <fantasai> Brad: Can you assign other properties to a grid cell?
718. # [19:56] <fantasai> Phil: Some, but mostly positioning stuff
719. # [19:57] <fantasai> Tab: If you have a slot created by the template property, can you reposition it using grid-rows and grid-columns?
720. # [19:57] <fantasai> Tab: I would prefer "no" :)
721. # [19:58] <fantasai> Tab: I would not want a designer to be confused about their slot moving around because a later definition moved it
722. # [19:58] <fantasai> plinss: I would prefer the cells to be defined where the template is defined.
723. # [19:59] <fantasai> Markus: You could do that too
724. # [19:59] <fantasai> plinss: I would prefer to have the template declaration to also include a list of defined cells
725. # [20:00] <fantasai> plinss: You could then use ::grid-cell() to style the slot
726. # [20:00] <fantasai> Phil: That starts making the template declaration really long and complicated.
727. # [20:00] <fantasai> Phil: I like breaking it up into bite-sized chunks
728. # [20:01] * Quits: stearns (c0961605@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
729. # [20:01] <fantasai> plinss: As a designer, I'd think of the template as a single thing. Don't like breaking it out like this.
730. # [20:02] <dbaron> plinss: I don't like the template ASCII art thing.
731. # [20:02] <fantasai> fantasai: You could use an @rule to put all the pieces together and give it a name @template mylayout { .... }
732. # [20:03] <fantasai> various people object and declare their love for the ASCII art thing
733. # [20:03] <smfr> can't hear a word plinss is saying
734. # [20:03] <fantasai> plinss: I think it's very 80s and very constrained and very silly
735. # [20:03] <fantasai> Markus: I was exactly in your camp when I first looked at it. We want to make it cleaner, more industrial strength, etc.
736. # [20:04] <fantasai> Markus: But then we started to try building something a little more complex with it
737. # [20:04] <bradk> : #grid::grid-cell("cell-start" "cell-end", "cell-start" "cell-end") { grid-cell-name: "cell" }
738. # [20:04] <fantasai> Markus: But as you start to have more complex grid structures, the ASCII art structure very easily and clearly represents those layouts
739. # [20:04] <fantasai> Markus: The problem is that it's not industrial strength. You run out of characters
740. # [20:05] <fantasai> howcome: Can we get some from the Chinese? :)
741. # [20:05] <fantasai> Markus: You have the power of both.
742. # [20:05] <dbaron> Phil: grid cells is a superset of template since you can do overlapping cells
743. # [20:06] * hober never wants to see slots named U+1F4A9 in ascii art
744. # [20:06] <dbaron> plinss: What happens if the "d"s in a template don't form rectangles?
745. # [20:06] <fantasai> Tab: You can't do that
746. # [20:06] <fantasai> Tab: They have to be rectangles
747. # [20:06] <fantasai> plinss: I have to draw rectangles in ASCII art?
748. # [20:06] <fantasai> glazou: It's ugly
749. # [20:07] <fantasai> Tab: As someone who edits CSS in a plaintext editor, I love this.
750. # [20:07] <fantasai> glazou: My goal is to make CSS editable without a text editor.
751. # [20:07] <fantasai> glazou: Without knowing about CSS.
752. # [20:07] <fantasai> Tab: It is really easy to create a UI for the ASCII art.
753. # [20:07] <fantasai> Markus: We are open to either way.
754. # [20:08] <fantasai> Steve: I agree with what Markus just said, which is that the argument is a red herring, provided that there is a clear relationship among each method of specifying the grid
755. # [20:09] <Bert> (The "ASCII art" was inspired by proprietary WYSIWYG template editors used by two mobile companies; although their output was HTML tables, not CSS.)
756. # [20:09] <fantasai> Steve: and that you cand round-trip between the two
757. # [20:10] <fantasai> fantasai: well, ascii art is a subset of the functionality of the other method, so you can't round-trip but there is a clear mapping between the two
758. # [20:10] <Bert> (Cesar has a WYSIWYG editor for templates themselves, made by a student.)
759. # [20:10] <fantasai> Steve: yes
760. # [20:10] <fantasai> Steve: that satisfies my requirements
761. # [20:11] <fantasai> Steve: talks about assinging multiple inlines into a single slot
762. # [20:11] <fantasai> Phil: I wasn't too clear on that point
763. # [20:11] <fantasai> Phil: If I were to float: left something I positioned into slot A, and positioned something else into slot A, would it flow around the float?
764. # [20:11] <fantasai> Bert: That was the intention, yes
765. # [20:12] <fantasai> something about overlapping
766. # [20:12] <fantasai> Tab: You could create multiple slots in the same place
767. # [20:12] <fantasai> Alex: Not sure you want to mix unrelated content from various pieces of the dom into a single flow
768. # [20:13] <fantasai> Bert: run-in has a similar problem, taking an element out of here and putting it there where it has to be reflowed
769. # [20:13] <fantasai> Steve: You're just creating a shadow element that's the combination of all the things you're flowing into the slot
770. # [20:13] <fantasai> Steve: and then you flow that
771. # [20:13] <fantasai> Alex: Yes, it's possible, but it becomes more complicated
772. # [20:13] <fantasai> Alex: If you really need it we could do it
773. # [20:13] <fantasai> Steve: The example from the spec is footnotes
774. # [20:14] <fantasai> Phil: Ok, let's note that and move on.
775. # [20:14] <fantasai> Phil: You declare a grid using the display property -- could be inline or block
776. # [20:14] <fantasai> Phil: We have a definition of grid items
777. # [20:14] <fantasai> Phil: You can put inline-blocks, block-level elements, various other items
778. # [20:14] <fantasai> Phil: These are wrapped in an anonymous block
779. # [20:15] <fantasai> Tab: We have more precise terminology for this stuff
780. # [20:15] <fantasai> (probably should look at 9.2 etc.)
781. # [20:16] <fantasai> Phil: You can name lines, or not name lines. They have an implicit name which is a number
782. # [20:16] <fantasai> Steve: Do you use direction and writing mode to determine these?
783. # [20:16] <fantasai> Phil: Yes
784. # [20:16] * Joins: stearns (c0961605@78.129.202.38)
785. # [20:17] <fantasai> Phil: I can put names by putting strings before the grid measurements.
786. # [20:17] <fantasai> Phil: I can put multiple names before a measurement, that gives it aliases
787. # [20:17] <fantasai> Phil: depending on your naming convention, this might be convenient
788. # [20:17] <fantasai> Phil: You specify a start and end line
789. # [20:17] <dbaron> Phil: There are also start and end lines predefined, which are keywords rather than strings.
790. # [20:18] <fantasai> glazou: I don't like that. A lot of authors are going to use the terms start and end
791. # [20:19] <fantasai> Phil: Not a syntactic conflict. There might be mental conflict. I've heard that several times...
792. # [20:19] <dbaron> fantasai: Can you count the numbers from the end rather than from the beginning.
793. # [20:19] <dbaron> Steve: e.g., if you allow negatives to count from end, 1 to -1 would be start to end
794. # [20:20] <fantasai> Phil: We also introduced syntax we borrowed from grid spec for repeating rows or columns
795. # [20:20] <fantasai> patterns
796. # [20:20] <fantasai> Phil: You might want, e.g. a content space and a gutter, content space, gutter.
797. # [20:21] <fantasai> Phil: We have a concept of repeating patterns for that
798. # [20:21] <fantasai> Phil: You can name the pattern, that applies to the first line in the pattern
799. # [20:21] <fantasai> Phil: This is useful for noting the start of the repeating run.
800. # [20:21] <fantasai> Phil: grid-columns: 10px ("content" 250px 10px)[4];
801. # [20:22] <fantasai> Steve: If i have this repeating pattern, and I shrink the window size, is there a way to drop columns?
802. # [20:22] <fantasai> Phil: Not in this spec. Although we have a concept of automatic columns and rows.
803. # [20:22] <fantasai> Alex: With grid positioning, repeat meant repeat this combination until you run out of space.
804. # [20:22] <fantasai> Phil: That's something you could add.
805. # [20:23] <fantasai> Steve: There's an interesting interaction between fractional space and that concept
806. # [20:23] <fantasai> Alex: Yeah, you can't combine them.
807. # [20:23] <fantasai> Alex: I think we resolved them to zero or something.
808. # [20:23] <fantasai> Tab: You could have repeating pattern, and fractional space on either side.
809. # [20:23] <fantasai> Tab: I think that's the only case it would make sense.
810. # [20:24] <fantasai> Alex: You could repeat fractions, but you'd wnat to resolve those first before repeating them.
811. # [20:24] <fantasai> Steve: You want an integral number of columns, use flex space algo to adjust columns or gaps as specified
812. # [20:25] <hober> repeat("content" 250px 10px, 4)
813. # [20:25] <fantasai> fantasai: Syntax comment -- we're trying to avoid using additional punctuation for something specific, in case we want to do something generic with it later. So I would suggest to use a functional notation.
814. # [20:25] <fantasai> Phil: We have some different sizing functions for tracks
815. # [20:25] <fantasai> Phil: Lenghts, percentages resolved against grid element size
816. # [20:26] <fantasai> Phil: Fractional values, which are resolved against the remaining space proportional to the number (relative to total of fractional values)
817. # [20:26] <fantasai> Phil: max-content, min-content keywords
818. # [20:26] <fantasai> Phil: fit-content
819. # [20:26] <fantasai> Phil: minmax defines a size range
820. # [20:26] <fantasai> Phil: auto keyword is equivalent to fit-content
821. # [20:27] <fantasai> Phil: Any questions on these?
822. # [20:27] <fantasai> Simon: Did you consider a comma-separated syntax?
823. # [20:27] <fantasai> Phil: We played with various syntaxes, but tried to avoid adding unnecessary characters
824. # [20:28] <fantasai> dbaron: If you have commas, you have lines and you have things for the spaces in between them. You have to then figure out where the commas would go.
825. # [20:28] <fantasai> Steve: good point
826. # [20:29] <fantasai> fantasai: You could use line breaks, since it's space-separated, which let's you break wherever you think make sense.
827. # [20:29] <fantasai> simon was concerned about readability with multiple names
828. # [20:29] <fantasai> Steve asks about flex vs fractional notation
829. # [20:30] <fantasai> Alex: Aiming to get flex and grid to have same sizing capabilities
830. # [20:30] <fantasai> Steve: My impression was that it's easier to use flex.
831. # [20:31] <fantasai> Steve: To get an equivalent mapping, it takes several nested minmax functions
832. # [20:31] <fantasai> Steve: A 5-tuple as a set of constraints is simple
833. # [20:31] <fantasai> Tab: Let's talk about that
834. # [20:31] <fantasai> [later]
835. # [20:32] <fantasai> Phil: Just a note on how values are computed.
836. # [20:32] <fantasai> Phil: You might have the same name appear multiple times in the grid value ...
837. # [20:32] * fantasai isn't getting this
838. # [20:33] <fantasai> Phil: auto grid column and row generation in case you refer to a gridline that doesn't exist
839. # [20:33] * Quits: anne (annevk@83.85.115.123) (Quit: anne)
840. # [20:33] <fantasai> Phil talks about used value serialization
841. # [20:34] <fantasai> CSSOM results
842. # [20:34] * Quits: stearns (c0961605@78.129.202.38) (Quit: http://www.mibbit.com ajax IRC Client)
843. # [20:34] <fantasai> glazou: Computed Value is extremely painful to parse
844. # [20:34] <fantasai> Simon: What's the alternative?
845. # [20:35] <fantasai> glazou: parsing the repeat notation is problematic
846. # [20:35] <fantasai> Simon: Thinking about gradients, how could that have been better?
847. # [20:35] <fantasai> glazou: For gradients need a better CSSOM
848. # [20:36] <fantasai> glazou: Think about users of getComputedStyle, expand everything
849. # [20:37] <fantasai> Phil: We wanted to be able to re-assign the value back into the OM and get the same result
850. # [20:37] <fantasai> Phil explains a complicated example
851. # [20:37] <fantasai> dbaron: I think it's important that it be round-trippable
852. # [20:38] <fantasai> dbaron: I think expanding it beyond what it was is causing it to be non-round-trippable.
853. # [20:38] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
854. # [20:38] <fantasai> dbaron: If you read in the grid , and there's an element that auto-generates lines, and you write back, and then you read in and remove the element, you wind up wit lots of extra grid lines that weren't there before
855. # [20:39] <fantasai> Phil: The grid-column and grid-row properites are used for positioning children of the grid
856. # [20:39] <fantasai> Phil shows the syntax propdfe tables
857. # [20:39] <fantasai> Phil: If you don't specify ? you get an implicit end column
858. # [20:39] <fantasai> s/column/line/
859. # [20:40] <fantasai> Phil: We said that items are placed in a cell.
860. # [20:40] <Bert> s/propdfe/propdef/
861. # [20:40] <fantasai> Phil: That doesn't necessarily mean the element stretches to fill the cell
862. # [20:40] <Bert> rrsagent, pointer?
863. # [20:40] <RRSAgent> See http://www.w3.org/2011/03/08-css-irc#T19-36-31
864. # [20:40] <fantasai> Phil: The cell is just a containing block
865. # [20:40] <fantasai> Phil: There's also the concept of explicitly defining the grid cells, which we covered before
866. # [20:40] <fantasai> Phil: with that name you can place more than one item into a cell
867. # [20:41] <fantasai> Steve: What do you mean by placing more than one item into a cell?
868. # [20:41] <fantasai> Phil: The default behavior is for these items to stack
869. # [20:42] <fantasai> one after the flow
870. # [20:42] <fantasai> Phil: whereas positioning them makes them overlap
871. # [20:42] <fantasai> Steve: That seems a little subtle
872. # [20:43] <fantasai> Phil: There's a property to control this, grid-cell-stacking
873. # [20:43] <fantasai> Phil: You can have things stack in rows or columns directions, or layer them
874. # [20:44] <fantasai> Phil: Perhaps the initial value here should be layer for ocnsistency
875. # [20:44] <fantasai> Steve: That would be better
876. # [20:44] <fantasai> Simon: ...
877. # [20:44] <fantasai> Phil: We intend that they are block-level or inline-block elements.
878. # [20:44] <fantasai> Phil: if they are valid grid items
879. # [20:45] <fantasai> Phil: There is also special sizing behavior, where the alignment properties for when you put an element into a grid-cell include stretch, start, end and center
880. # [20:45] <fantasai> Phil: There's a row alignment and a column alignment
881. # [20:45] <fantasai> Phil: If you take a block-level element and assign it a grid-column-align property other than stretch, then it will align to one of the edges of its grid-cell and size itself shrink-to-fit
882. # [20:46] <fantasai> Phil: relationship between that and stacking items in a grid cell
883. # [20:46] <fantasai> Phil: default is to stretch
884. # [20:46] <fantasai> Phil: so it stretches to occupy the whole cell
885. # [20:46] <fantasai> Phil: But if you're stacking, the elements will size shrink-to-fit so you can put one on top of the other
886. # [20:46] <Bert> rrsagent, this meeting spans midnight
887. # [20:46] <RRSAgent> ok, Bert; I will not start a new log at midnight
888. # [20:47] <fantasai> Phil explains something more about sizing, several people look confused
889. # [20:47] * Joins: stearns (stearns@192.150.22.5)
890. # [20:48] <fantasai> Phil talks too fast
891. # [20:48] <fantasai> Steve: Sounds sort of like each of these cells is a flexbox in what you're doing, with the flex direction being either rows or columns
892. # [20:48] <fantasai> Phil: No flex, but yes similar
893. # [20:49] <fantasai> Steve: Each item that's stacked is being handled as if it were a flex item whose size is based on its content. I.e. it beocmes a BFC, there's no margin collapsing, etc.
894. # [20:49] <fantasai> Phil scans through sections of the draft defining the various properites
895. # [20:50] <dbaron> fantasai: What if grid-row specifies and a start and an end line, and grid-row-span also specifies a span? Could have a cascading problem too.
896. # [20:50] <dbaron> Phil: We should make it clear that an ending line has priority over a span.
897. # [20:50] <fantasai> Phil: We left in grid-row-span, grid-column-span, because we liked that ability more
898. # [20:51] <fantasai> Phil: There's a concept of implicit columns or rows
899. # [20:51] <fantasai> Phil: You create auto tracks as needed
900. # [20:51] <fantasai> Phil: There's a property to control what size track gets created, so that they're not always auto-sized
901. # [20:52] <fantasai> Phil: Lastly, concept of automatically placing items in the gird.
902. # [20:52] <fantasai> Phil: There's a concept of grid-flow, which creates more rows (or columns) as needed.
903. # [20:52] <fantasai> Phil: Would take awhile to explain, take a look at the draft
904. # [20:52] <fantasai> Steve: this is for indefinite numer of coluns?
905. # [20:53] <fantasai> Phil: Yeah. I have a form with lots of fields, as an author just want to define a grid for your fields
906. # [20:53] <fantasai> Phil: I create three columns, and then tell the forms to find an auto row
907. # [20:54] <fantasai> Phil: Here are the grid alignment properites, discusses writing mode interactions, etc.
908. # [20:55] <fantasai> Phil: Drawing order of grid items is not changed; got some feedback on using z-index, haven't incorporated yet
909. # [20:55] <fantasai> Phil: Concern is wanting to drop things behind other things, but not behind the grid element background
910. # [20:55] <fantasai> Phil talks about stacking contexts
911. # [20:57] <fantasai> Phil: Need an easy send-to-back functionality
912. # [20:57] <fantasai> dbaron: A full stacking context would do that
913. # [20:57] <fantasai> Phil: Not sure we really want to prevent z-ordering behind the grid element just because we want easy send-to-back
914. # [20:58] <fantasai> dbaron: You don't have to do that by default, but the author could specify it themselves
915. # [20:58] <fantasai> dbaron: That makes the send-to-back scenario work
916. # [21:00] <fantasai> Phil: Stacking contexts are complicated, I'm concerned about making authors understand them and z-index in order to make this work.
917. # [21:00] <fantasai> Alex explains something about making all form controls relpos just to get z-index working
918. # [21:01] <fantasai> fantasai: What is the relationship of this to existing grid module?
919. # [21:01] <fantasai> Alex: Positioning is really interesting in concept of page layouts, and we have some ideas on how to integrate them
920. # [21:02] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
921. # [21:02] <fantasai> Alex: I have some ideas on how to integrat them
922. # [21:02] * Quits: smfr (smfr@63.245.220.224) (Quit: smfr)
923. # [21:02] <fantasai> fantasai: It seems this module folds in a lot of that functionality, so you could publish this as an update to that module.
924. # [21:03] <fantasai> Alex: Grid positioning deals with other content, no necessarily your immediate children
925. # [21:03] <fantasai> Alex: One thing that needs to be defined is element sizing, and how do you define a positioning container ... where grid is applicable
926. # [21:04] <fantasai> Alex: Once we figures out where grid position is applicable, who is the grid positioning container, and how is the grid defined on that, we can easily merge these specs together
927. # [21:05] <fantasai> Alex: So that everything here contributes to grid definition.
928. # [21:05] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Client exited)
929. # [21:05] <fantasai> Markus: We still need a lot of the concepts from that spec to integrate.
930. # [21:05] <fantasai> Alex: I think the main ue case for grid positioning is page floats
931. # [21:06] <fantasai> Alex: I don't think page floats is quite as ready
932. # [21:07] * fantasai suggests css3-grid-layout :)
933. # [21:07] <fantasai> fantasai: Ok, I understand why they are separate and I agree that makes sense.
934. # [21:08] <fantasai> <br type="lunch">
935. # [21:09] * Ms2ger suggests css3-kitchen-sink-layout :)
936. # [21:10] * Quits: TabAtkins_ (tabatkins@63.245.220.224) (Ping timeout)
937. # [21:17] * Quits: stearns (stearns@192.150.22.5) (Quit: Leaving...)
938. # [21:35] * Zakim excuses himself; his presence no longer seems to be needed
939. # [21:35] * Parts: Zakim (rrs-bridgg@128.30.52.169)
940. # [21:35] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
941. # [21:38] * Joins: stearns (stearns@192.150.22.5)
942. # [21:40] * Quits: dsinger (dsinger@17.72.147.117) (Ping timeout)
943. # [21:45] * Parts: stearns (stearns@192.150.22.5)
944. # [21:45] * Joins: stearns (stearns@192.150.22.5)
945. # [22:04] * Quits: Arron (arronei@63.245.220.224) (Ping timeout)
946. # [22:06] * Joins: Arron (arronei@63.245.220.224)
947. # [22:07] * Joins: mmielke (mmielke@63.245.220.224)
948. # [22:07] * Joins: Zakim (rrs-bridgg@128.30.52.169)
949. # [22:09] * Joins: smfr (smfr@63.245.220.224)
950. # [22:10] * Quits: shonda (shonda@63.245.220.224) (Ping timeout)
951. # [22:11] * Joins: TabAtkins_ (tabatkins@63.245.220.224)
952. # [22:11] <fantasai> </br>
953. # [22:11] * fantasai thinks that's an accurate description :P
954. # [22:11] <fantasai> Markus: Wanted to follow up on discussion from before-lunch meeting
955. # [22:12] <fantasai> Markus: Would like to advance grid layout spec from editor's draft to WD
956. # [22:12] <fantasai> jdaggett: For FPWD, there are special requirements
957. # [22:12] * Joins: glazou (glazou@63.245.220.224)
958. # [22:13] <glazou> test
959. # [22:13] * Quits: howcome (howcome@63.245.220.224) (Ping timeout)
960. # [22:13] <fantasai> fantasai: From what Alex was saying, I think it makes sense for the modules to be separate
961. # [22:13] <fantasai> [howcome asked if we can merge them]
962. # [22:13] <fantasai> fantasai: And publish this as grid-layout
963. # [22:14] * Joins: Jay (jay@63.245.220.224)
964. # [22:14] <fantasai> jdaggett: What are the requirements?
965. # [22:14] <fantasai> glazou: Has to be in the charter
966. # [22:15] <fantasai> fantasai: It is, since it's closely related to existing css3-grid
967. # [22:15] <fantasai> fantasai: need permission from plh to publish FPWD, but nothing else
968. # [22:16] <fantasai> RESOLVED: Publish as css-grid, i.e. CSS Grid Layout [Level 1]
969. # [22:16] <fantasai> ACTION Bert make publication
970. # [22:16] * trackbot noticed an ACTION. Trying to create it.
971. # [22:16] <trackbot> Created ACTION-312 - Make publication [on Bert Bos - due 2011-03-15].
972. # [22:16] <fantasai> s/css-grid/css-grid-layout/
973. # [22:17] * Joins: karl (karlcow@128.30.54.58)
974. # [22:17] <fantasai> note: level 1 is not part of title, just clarifying that no other level is
975. # [22:18] <fantasai> plinss: Skipping line grid, since it's marked as "if time allowed"
976. # [22:18] <fantasai> plinss: Flexbox?
977. # [22:18] <fantasai> Tab: ???
978. # [22:18] <fantasai> Alex: Wouldn't you like to present the changes in your latest draft?
979. # [22:18] <fantasai> Tab: I could?
980. # [22:18] * Joins: shonda (shonda@63.245.220.224)
981. # [22:18] <fantasai> Tab goes up to present
982. # [22:18] <plinss_> s/Skipping line/Deferring line/
983. # [22:19] <arno1> Moved "Line Grid" to end of agenda for today on wiki
984. # [22:19] <fantasai> Tab gives overview of flexbox
985. # [22:19] <smfr> http://dev.w3.org/csswg/css3-flexbox/
986. # [22:20] <fantasai> Tab: Current editor's draft of flexbox is much closer to my draft, and to suggestions we've made so far
987. # [22:20] <fantasai> Tab loads page with lots of red
988. # [22:20] <fantasai> Tab: Using term flexbox consistently, instead of box which is too generic
989. # [22:20] <fantasai> Tab: Flex-direction says which directions the boxes flow in
990. # [22:21] <fantasai> Tab: Have physical and logical directions
991. # [22:21] <fantasai> Alex: If we had a multiline flexbox, how would we extend flex direction for it?
992. # [22:21] <fantasai> ISSUE ^
993. # [22:21] <fantasai> Alex: One approach would be to use existing writing mode
994. # [22:21] <fantasai> Alex: There is no logical equivalent of those
995. # [22:22] <fantasai> Alex: Maybe do come up with eight logical abbreviation directions
996. # [22:22] * Joins: bradk_ (bradk@63.245.220.224)
997. # [22:23] <fantasai> fantasai: How about combining keywords with spaces, e.g. tb lr
998. # [22:23] <fantasai> Tab: flex-order lets you reorder items
999. # [22:24] * Quits: bradk_ (bradk@63.245.220.224) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
1000. # [22:24] * Joins: bradk_ (bradk@63.245.220.224)
1001. # [22:24] <fantasai> Tab: Flexible lengths is where it really changes.
1002. # [22:24] <fantasai> Tab: Old draft used a flex property that took an integer, and then keywords for alignment
1003. # [22:24] <fantasai> Tab: I'm going with a different approach here,
1004. # [22:25] <fantasai> Tab: Got feedback from daniel and web authors that "width" being an input in to the flex algo and not really the width was confusing
1005. # [22:25] <fantasai> Tab: Using now a flex() function, which takes 3 args, first one is positive flex, second is negative flex --
1006. # [22:26] <fantasai> Tab: Established at F2F that negative and positive flex should be distinguished, otherwise you get unintuitive results, ie. largest thing becoming smallest
1007. # [22:26] <fantasai> Tab: Third arg is the starting width.
1008. # [22:26] * Quits: sylvaing (sylvaing@63.245.220.224) (Ping timeout)
1009. # [22:27] <fantasai> Tab: auto gives previous behavior; it's always additive flex, but by default this arg is zero so you get absolute flex if you don't specify
1010. # [22:27] <dbaron> Phil: Is there plan to have something not flex-prefixed for any type of layout not based on source order?
1011. # [22:27] * Joins: sylvaing (sylvaing@63.245.220.224)
1012. # [22:27] <dbaron> (regarding flex-order)
1013. # [22:27] <fantasai> Phil asks about having the reordering be a more generic concept, since it's useful in many layout models not just for flexboxy
1014. # [22:27] <fantasai> s/y//
1015. # [22:28] <fantasai> Tab: Ok, could have that be a generic mechanism for rewriting source order
1016. # [22:28] <fantasai> Steve: ...
1017. # [22:28] <fantasai> Phil: Template layout had an area that used source order for flowing items, might want to reorder in that as well
1018. # [22:29] <fantasai> dbaron: Do people have positive experiences using an integer-ordering property like this?
1019. # [22:29] <fantasai> dbaron: or does this get unweildy with more content?
1020. # [22:29] <fantasai> Tantek: numbering BASIC worked so well!
1021. # [22:30] <fantasai> Steve: Might want to reorder columns
1022. # [22:30] <fantasai> Steve: in that case maybe using names
1023. # [22:30] <fantasai> Tab: Elika brought up case of tabbed layouts, where active tab is always in front
1024. # [22:30] <fantasai> Tab: I'm certain like many of our advanced tools it can be abused
1025. # [22:30] <fantasai> Tab: Like we shouldn't be sorting lists with this
1026. # [22:31] <fantasai> Tab: But I'm not sure how else to get the functionality we need here
1027. # [22:31] <fantasai> dbaron: Wrt usefulness of order, Gecko has implemented box-ordinal-group for around a decade now.
1028. # [22:31] <fantasai> dbaron: But it's used so rarely that we're still getting very fundamental bugs filex on it
1029. # [22:32] <fantasai> Tab returns to flex()
1030. # [22:32] <fantasai> Tab: The old flex property and box-align properties are replaced with flex() notation
1031. # [22:32] <fantasai> Tab: Then we have the flex-pack property, which determines the distribution of content within the flex direction
1032. # [22:33] <fantasai> Tab: It works similar to text-align
1033. # [22:34] <fantasai> Tab: justify evenly spaces out the flexboxes, aligning them flush
1034. # [22:34] <fantasai> fantasai: I would suggest to look at ruby-align property, esp distribute (which seems like a better name here) and distribute-space
1035. # [22:34] <fantasai> Tab: flex-align property..
1036. # [22:34] <fantasai> Tab: Normally use flex to do alignment, but couldn't figure out how to do baseline alignment
1037. # [22:35] <fantasai> Tab: Not totally clear on the use cases, so still haven't fully specc'ed it out.
1038. # [22:35] <fantasai> Tab: auto just means normal flex distribution, baseline means currently-undefined magic
1039. # [22:35] <fantasai> Tab: That's pretty much it, rest is algorithms
1040. # [22:36] * fantasai notes that flex-align could get a generic name and solve some other important problems like vertical alignment of boxes
1041. # [22:36] <fantasai> Tab: We've established that for flex, we want positive flexibility, negative flexibility, and a starting width. These are all important pieces of information we need to flex correctly.
1042. # [22:37] <fantasai> Tab: The original approach of having two different properties that have to be thought of together to get a single effect was confusing
1043. # [22:37] <fantasai> Tab: And with negative flex we needed yet another one
1044. # [22:37] <fantasai> [Markus asked why there's flex() instead of 'flex']
1045. # [22:37] * glazou after boustrophedon, we need to introduce the word "stoïchédon" into CSS :-)
1046. # [22:38] <fantasai> Alex: My concern is that it makes absolute flex easier but relative flex harder
1047. # [22:38] <fantasai> Alex: The main working mode of the whole spec becomes absolute flex, which is not the previous system
1048. # [22:39] <fantasai> Alex: I expected default starting width to be auto
1049. # [22:39] <fantasai> Alex: Have padding initial be zero, width initial be auto
1050. # [22:40] <fantasai> Markus: ...
1051. # [22:41] <fantasai> Tab: Talking to authors playing with old spec, they're confused.
1052. # [22:41] <fantasai> Tab: Having flex: 1; on multiple elements result in different sizes confuses them
1053. # [22:42] <fantasai> Alex: If you're working on top-level page layout, absolute flex is more useful
1054. # [22:42] <fantasai> Alex: If you're laying out form controls, then additive flex is more useful.
1055. # [22:42] <dbaron> s/form controls/form controls or menus/
1056. # [22:42] <fantasai> Tab: I have to make one shorter syntax than the other
1057. # [22:42] <fantasai> Alex: Let's look at other options
1058. # [22:43] <fantasai> Tab talks about terminology for width and height algos
1059. # [22:43] <fantasai> Markus: Is your motivation that this would replace existing flexbox spec?
1060. # [22:43] <fantasai> Tab: Yes, replace
1061. # [22:44] <fantasai> Markus: Despite existing implementations?
1062. # [22:44] <fantasai> Tab: Yes. I think this is sufficiently better that it should replace.
1063. # [22:44] <fantasai> Tab: Working with chrome devs, they are enthusiastic about replacing it
1064. # [22:44] <fantasai> Alex: Is Mozilla going to move to the new syntax?
1065. # [22:44] <fantasai> dbaron: We'd definitely like to have a standard version of flexbox.
1066. # [22:45] <fantasai> dbaron: It's hard to tell how quickly it would happen/
1067. # [22:45] <fantasai> Alex: would it make a difference if it stayed closer to the old syntax?
1068. # [22:45] <fantasai> dbaron: I think the syntax is less of a big deal than the concepts
1069. # [22:45] <fantasai> dbaron: A lot of the stuff we use flexbox for now is stuff we want additive flex for now.
1070. # [22:45] <fantasai> dbaron: potentially harder to convert existing content
1071. # [22:46] <fantasai> Tab: I don't buy the conversion argument
1072. # [22:46] <fantasai> dbaron: But it seems like a lot of typing
1073. # [22:46] <dbaron> people might not know what flex(1, 0, auto) means
1074. # [22:46] <fantasai> dbaron: And I don't think people will know what flex(1,0,auto) means
1075. # [22:46] <dbaron> (which they'll be using a lot)
1076. # [22:47] <fantasai> Markus: Shouldn't we standardize the current spec now?
1077. # [22:47] <fantasai> Markus: And make this the next level?
1078. # [22:47] <fantasai> Tab: You can't really do that. They're not compatible, not without some really hacky stuff
1079. # [22:47] <fantasai> Tab: Also my experience talking with authors is that the current spec is really confusing
1080. # [22:48] <fantasai> Markus: Yeah, it's not that great, but we have implementations
1081. # [22:48] <fantasai> Tab: I'm not in favor of standardizing something that's bad.
1082. # [22:49] <fantasai> dbaron: I think you're getting different feedback because the web authors you're talking with are trying flexbox for something it wasn't designed for
1083. # [22:49] <glazou> standardization is always bad because it is always a compromise
1084. # [22:50] <Bert> i/Arno: I'd like tot/-> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf CSS Regions draft
1085. # [22:50] <fantasai> fantasai: So, my position is [minute here later]
1086. # [22:50] * Ms2ger always enjoys seeing glazou in favour of standards ;)
1087. # [22:51] <fantasai> Tab: If it's a question of which (additive vs absolute) is easier, I'm not concerned about that question
1088. # [22:51] <fantasai> Tab: What's important to me is breaking with the previous syntax.
1089. # [22:51] <fantasai> Markus: We have implementations coming, and it's used.
1090. # [22:51] <fantasai> Tab: But not on the Web
1091. # [22:51] <fantasai> Tab: And our implementation at least is very buggy
1092. # [22:51] <fantasai> Tab: It's a minority prefixed thing.
1093. # [22:52] <fantasai> glazou: Current implementations are too weak and too buggy for use
1094. # [22:52] <fantasai> Tantek: That's the point of prefixes -- they allow us to experiment.
1095. # [22:53] <fantasai> fantasai rants, but doens't have time to type it
1096. # [22:53] * Quits: Ms2ger (Ms2ger@91.181.118.178) (Quit: nn)
1097. # [22:54] <fantasai> dbaron: I don't think negative flex is the hardes thing here, it's adding flex to margins and padding
1098. # [22:54] <fantasai> fantasai: But thats needed if you want to apply this to HTML, because in XUL you have to use <spacer> elements
1099. # [22:54] <dbaron> dbaron: ...and as a value to existing properties
1100. # [22:54] <fantasai> Steve: ...
1101. # [22:54] <fantasai> Steve: This in my mind has the level of flexibility that you need
1102. # [22:55] <fantasai> Steve: It's also a lot easier to explain to people than the other one
1103. # [22:56] <fantasai> Steve: It would work perfectly well within the grid layout model
1104. # [22:56] <fantasai> Steve: I think Tab's choice of using the zero-width thing is more appropriate there
1105. # [22:57] <fantasai> Tab: For the most common case, of starting flex from the auto width and using single flex, you can just use 'auto'
1106. # [22:57] <fantasai> Tab: That's equal to flex(1,0,auto)
1107. # [22:57] <fantasai> Tab: We can still talk about how to make them easy, but there are ways to make both common cases easy
1108. # [22:57] <fantasai> dbaron: Shouldn't the width value come first?
1109. # [22:58] <dbaron> Tab: I had it that way at first; seemed reasonable; Alex convinced me to change.
1110. # [22:59] <fantasai> Tab: I had that first, and it makes it easier to do relative flex, but it doesn't work so well for absolute flex
1111. # [22:59] <fantasai> Tab: And Alex suggested swapping the order
1112. # [23:00] <fantasai> fantasai asks about making flex() detec whether it's aboslute or relative based on whether it's a length or an integer
1113. # [23:00] <fantasai> Steve: ...
1114. # [23:01] <fantasai> Steve: The flex unit is confusing if grow and shrink are given in one set of units, and differnt in another
1115. # [23:01] <fantasai> Tab^: I had flex units be additive and flex() be absolute before
1116. # [23:01] <fantasai> ...
1117. # [23:01] <fantasai> Tab: The idea of what's the best way to present this concept to authors is omething we should talk about
1118. # [23:02] <fantasai> Steve: Btw I'm not disputng the 5-tuples
1119. # [23:02] <fantasai> Steve: Just discussing synta
1120. # [23:02] <fantasai> Tab: I think this is the best option, though I'm open to other options.
1121. # [23:02] <fantasai> Tab: Main question is whether we go forward with this or revert to the old draft.
1122. # [23:03] <fantasai> Alex: We want draft to become stable and move forward
1123. # [23:03] <fantasai> Alex: I don't see a way to get there without having a new draft
1124. # [23:03] <fantasai> plinss asked for objections to moving forward with this draft
1125. # [23:03] <fantasai> RESOLVED: Publish updated draft of css3-flexbox
1126. # [23:04] <fantasai> Topic: MultiCol
1127. # [23:04] <fantasai> howcome: Multicol is in CR. We have a couple of issues, but close to getting a new version
1128. # [23:04] <fantasai> howcome: Would like to publish another CR
1129. # [23:05] <fantasai> howcome: Big issue was pseudo-algorithm
1130. # [23:05] <fantasai> howcome: In previous versions the pseudo-algorithm tried to reduce the number of columns
1131. # [23:06] <fantasai> howcome: Seems to be consensus on not doing that, and relying on authors setting column-width to give the columns a minimum width
1132. # [23:06] <fantasai> howcome: here's what I suggest to edit the pseudo-algorithm
1133. # [23:07] <fantasai> fantasai: Can we get comments in the pseudo-algorithm?
1134. # [23:07] <fantasai> howcome: maybe
1135. # [23:07] <fantasai> howcome: I think my proposal is correct, put a max fuction to make sure width doesn't go negative
1136. # [23:08] <fantasai> howcome: The prose says that if both 'column-width' and 'column-count' have non-auto values, the integer value describes the maximum number of columns
1137. # [23:08] <fantasai> howcome: fantasai noted this in the minutes
1138. # [23:08] <fantasai> howcome: But this prose is not included in the pseudo-algorithm
1139. # [23:08] <fantasai> Sylvain: Fix the pseudo-algorithm
1140. # [23:11] <fantasai> Discussion of use cases for column-count
1141. # [23:12] * Joins: brennannovak (brennannov@207.98.72.174)
1142. # [23:12] <fantasai> howcome: btw, my proposal for fixing this should use min() instead of max() ...
1143. # [23:12] * Parts: brennannovak (brennannov@207.98.72.174)
1144. # [23:15] <fantasai> fantasai makes an argument that the combination of column-width and column-count is the most useful way of specifying column-count, and this behavior is not provided by any of the alternative proposals
1145. # [23:15] <fantasai> wheres the behavior of the alternative proposals can be gotten in other ways
1146. # [23:15] <fantasai> Simon: Should we rename it to column-min-width?
1147. # [23:15] <fantasai> howcome: we'd have to go back to last call
1148. # [23:16] <fantasai> no strong opinions in favor of renaming
1149. # [23:16] <fantasai> howcome: Can we update the CR?
1150. # [23:17] <fantasai> plinss wants to be more verbose and have it column-min-width
1151. # [23:18] <fantasai> fantasai disagrees
1152. # [23:18] <fantasai> Brad: If there's only one thing to set the widht, it should just be width
1153. # [23:18] <fantasai> RESOLVED: Publish updated WD of css3-multicol
1154. # [23:18] <fantasai> RESOLVED: Publish updated CR of css3-multicol
1155. # [23:18] <fantasai> dbaron: test suite?
1156. # [23:18] * Joins: dsinger (dsinger@17.72.146.85)
1157. # [23:19] <fantasai> howcome: I'm working on the test suite
1158. # [23:19] <fantasai> dbaron: we have 22 reftests for columns
1159. # [23:20] <fantasai> fantasai: bunch more in pagination
1160. # [23:20] <fantasai> dbaron: we'd need to go back and check that the tests match the current spec
1161. # [23:20] <fantasai> johnjan: I have some ideas
1162. # [23:20] <fantasai> howcome: how do we go forward with the tests
1163. # [23:21] <fantasai> johnjan: We should take what we learned about CSS2.1 and apply to CSS3
1164. # [23:21] <fantasai> johnjan: I think first we should map every test to the part of the spec's testing
1165. # [23:22] * Bert rrsagent, draft minutes
1166. # [23:22] <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert
1167. # [23:22] <fantasai> dbaron, fantasai: We have links to section headings laready
1168. # [23:22] <fantasai> fantasai: css3 specs have more fine-grained subsections than CSS2.1
1169. # [23:23] <fantasai> johnjan, fantasai: ideally would do per-paragraph anchors
1170. # [23:23] <fantasai> fantasai: but hard to have stable anchors
1171. # [23:24] <Bert> i/I'd like tot talk/-> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf CSS Regions draft
1172. # [23:24] * Bert rrsagent, draft minutes
1173. # [23:24] <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert
1174. # [23:24] <dbaron> http://test.csswg.org/suites/css2.1/20110111/xhtml1/toc.xht
1175. # [23:24] <fantasai> johnjan talks about testing
1176. # [23:24] <fantasai> keeping track of which sections are tested, not tested,
1177. # [23:25] <fantasai> how many tests are for each section
1178. # [23:25] <fantasai> johnjan: we're not interested in implementation testing, but in implementability testing
1179. # [23:25] <fantasai> dbaron: We need a test suite to enter PR, but that shouldn't be the only purpose of the test suite.
1180. # [23:25] <fantasai> dbaron: I think we should be developing the test suite for interop
1181. # [23:26] <fantasai> dbaron: We want the test suite to solve real problems for authors, not just get us to PR
1182. # [23:26] <fantasai> dbaron: Authors have problems when impls don't do the same thing
1183. # [23:27] <fantasai> dbaron: And we want to test things that will have bugs that bother them
1184. # [23:27] <dbaron> It's not about proving interop... it's about improving interop.
1185. # [23:27] <fantasai> johnjan: proving compliance and interop are two different
1186. # [23:27] <Bert> i|I'd like tot talk|-> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf CSS Regions draft
1187. # [23:27] * Bert rrsagent, draft minutes
1188. # [23:27] <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert
1189. # [23:28] <fantasai> dbaron: It's not about proving interop, it's about IMproving it
1190. # [23:28] <fantasai> ...
1191. # [23:29] <fantasai> johnjan: There's no motivation for making test suites other than going to CR
1192. # [23:29] <alexmog> what if test ID used a section URL plus the text of the paragraph? then mapping can use simple search to map. when paragraph moves it is still mapped to. when the pargarph changes the tests have to be updated anyway...
1193. # [23:29] <fantasai> sylvaing: You could say that you need an implementation report to drop your prefixes
1194. # [23:29] <fantasai> sylvaing: Today, we allow dropping prefixes as soon as we go to CR.
1195. # [23:30] <fantasai> sylvaing: If we require tests, that gets us tests and it makes sure that impls dropping prefixes implemented it correctly
1196. # [23:30] <fantasai> johnjan: I think testing has to drive the process more
1197. # [23:31] <fantasai> fantasai: public-css-testsuite and the svn repo are available to all css modules, not just 2.1
1198. # [23:33] <fantasai> fantasai and arronei review the review process
1199. # [23:33] <fantasai> http://wiki.csswg.org/test
1200. # [23:33] <fantasai> Tab: There should be an excuse to why it's not a reftest
1201. # [23:34] <fantasai> dbaron: Did we adopt the scripted reftest conventions?
1202. # [23:34] <fantasai> fantasai: Not yet, we'd have to do so
1203. # [23:35] <fantasai> dbaron explains reftest-wait
1204. # [23:36] <fantasai> howcome: do we need scripted tests?
1205. # [23:36] <fantasai> dbaron: Yes, changing pagination points
1206. # [23:36] <fantasai> johnjan: resizing the window
1207. # [23:37] <fantasai> howcome: Safari?
1208. # [23:37] <fantasai> Simon: We have 50-60 tests in our test suite
1209. # [23:37] <fantasai> Simon: But they're not really suitable for test suite tests in their current incarnation
1210. # [23:38] <fantasai> howcome: What about multi-col in vertical text?
1211. # [23:38] <fantasai> Alex: It should just work :)
1212. # [23:39] <fantasai> johnjan: what about prefixes?
1213. # [23:40] <fantasai> Arron: No prefixes in the test suites
1214. # [23:40] <fantasai> johnjan: So we can't test until we drop prefixes
1215. # [23:40] <fantasai> dbaron: Could add prefixes with regexp
1216. # [23:41] * Joins: homata__ (homata@58.158.182.50)
1217. # [23:42] <fantasai> fantasai: Current build system has concept of output formats, would be easy to build regexp into that
1218. # [23:42] * Joins: mollydotcom (mollyh@173.164.174.193)
1219. # [23:42] <fantasai> Arron: Another issue is tracking issues on the testcases
1220. # [23:42] <fantasai> Arron: Using the mailing list is really really unweildy
1221. # [23:43] <fantasai> Arron: Can we use bugzilla?
1222. # [23:43] * Quits: homata (homata@58.158.182.50) (Ping timeout)
1223. # [23:44] <fantasai> johnjan: The mailing list is really going to be hard to manage
1224. # [23:44] <fantasai> dbaron: Bugzilla is too heavyweight
1225. # [23:44] <fantasai> plinss: we have a design for a system, just need to build it
1226. # [23:45] <fantasai> johnjan: We need something now
1227. # [23:45] <fantasai> Arron: May not be perfect solution, but Bugzilla gives us something for now
1228. # [23:46] <fantasai> fantasai: So I think we should adopt Bugzilla, one bug report per test unless you have a really good reason not to.
1229. # [23:47] <fantasai> howcome: So we put tests in contributors directory, and if I review and approve them I move them to the approved/ directory
1230. # [23:47] * Quits: bradk_ (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
1231. # [23:47] <fantasai> fantasai, arron: right
1232. # [23:47] <fantasai> RESOLVED: Use Bugzilla for test suite bugs, one bug report per test unless there's a good reason not to
1233. # [23:48] * mollydotcom says yay, that's good news
1234. # [23:49] * Quits: arno1 (arno@192.150.10.200) (Ping timeout)
1235. # [23:49] <fantasai> <br>
1236. # [23:53] <mollydotcom> hey folks - I'm much on the mend now - wondering if I should come in? Or rest and wait 'til tomorrow?
1237. # [23:54] <mollydotcom> (ps it's not contagious ;))
1238. # [23:56] * Quits: szilles (chatzilla@63.245.220.224) (Ping timeout)
1239. # [23:58] * sylvaing thinks molly is welcome anytime but suggests taking the rest of the day off :)
1240. # [23:59] <mollydotcom> That's very sweet, Sylvain. I think I will stay and rest here as there's not much time left of the day. Better to be feeling more myself tomorrow
1241. # Session Close: Wed Mar 09 00:00:00 2011

The end :)