/irc-logs / w3c / #css / 2012-10-29 / end

Options:

1. # Session Start: Mon Oct 29 00:00:00 2012
2. # Session Ident: #css
3. # [00:10] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 20 seconds)
4. # [00:16] * Quits: drublic (~drublic@public.cloak) (Client closed connection)
5. # [00:54] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 20 seconds)
6. # [00:57] * Quits: krit (~krit@public.cloak) ("Leaving.")
7. # [03:48] * Joins: krit (~krit@public.cloak)
8. # [04:46] * Joins: krit1 (~krit@public.cloak)
9. # [04:46] * Quits: krit (~krit@public.cloak) (Client closed connection)
10. # [05:20] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 20 seconds)
11. # [06:25] * Joins: isherman1 (~Adium@public.cloak)
12. # [06:26] * Quits: isherman (~Adium@public.irc.w3.org) (Ping timeout: 20 seconds)
13. # [07:09] * Quits: krit1 (~krit@public.cloak) ("Leaving.")
14. # [07:18] * Joins: krit (~krit@public.cloak)
15. # [07:20] * Joins: cabanier (~cabanier@public.cloak)
16. # [07:30] * Joins: SimonSapin (~simon@public.cloak)
17. # [07:31] * sylvaing_away is now known as sylvaing
18. # [07:39] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
19. # [08:05] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
20. # [08:18] * Joins: antonp (~Thunderbird@public.cloak)
21. # [08:30] * leaverou is now known as leaverou_away
22. # [08:43] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 20 seconds)
23. # [08:45] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 20 seconds)
24. # [08:52] * Quits: krit (~krit@public.cloak) ("Leaving.")
25. # [08:53] * Joins: JohnJansen (~JohnJansen@public.irc.w3.org)
26. # [08:53] * Joins: tomoyuki (~tshimizu3@public.cloak)
27. # [08:54] * Quits: JohnJansen (~JohnJansen@public.irc.w3.org) ("Page closed")
28. # [08:55] * Joins: JohnJansen (~JohnJansen@public.irc.w3.org)
29. # [08:56] * Quits: JohnJansen (~JohnJansen@public.irc.w3.org) ("Page closed")
30. # [08:57] * Joins: JohnJansen (~JohnJansen@public.irc.w3.org)
31. # [08:58] <JohnJansen> I'm observing in the Browser Testing and Tools WG this morning.
32. # [09:04] * Joins: Zakim (zakim@public.irc.w3.org)
33. # [09:04] <plinss> rrsagent make logs public
34. # [09:05] <plinss> zakim, this will be style
35. # [09:05] <Zakim> I do not see a conference matching that name scheduled within the next hour, plinss
36. # [09:05] * Joins: Kid (~Kid@public.cloak)
37. # [09:05] <plinss> rrsagent, pointer?
38. # [09:05] <RRSAgent> See http://www.w3.org/2012/10/29-css-irc#T08-02-05
39. # [09:10] * Joins: SteveZ (~chatzilla@public.cloak)
40. # [09:11] * leaverou_away is now known as leaverou
41. # [09:11] * Joins: shepazu (schepers@public.cloak)
42. # [09:12] * Quits: shepazu (schepers@public.cloak)
43. # [09:12] * Joins: shepazu (schepers@public.cloak)
44. # [09:13] * Joins: liam (liam@public.cloak)
45. # [09:13] * liam is now known as Liam|XMLCore
46. # [09:15] * Joins: cabanier (~cabanier@public.cloak)
47. # [09:15] * Joins: Rossen (~Rossen@public.cloak)
48. # [09:15] * Joins: krit (~krit@public.cloak)
49. # [09:16] * Joins: stearns (~anonymous@public.cloak)
50. # [09:17] * Joins: plh (plehegar@public.cloak)
51. # [09:18] * Joins: SimonSapin (~simon@public.cloak)
52. # [09:18] * Joins: franremy (~franremy@public.cloak)
53. # [09:21] * Joins: glazou (~glazou@public.cloak)
54. # [09:21] * Joins: antonp (~Thunderbird@public.cloak)
55. # [09:21] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
56. # [09:21] * Joins: dbaron (~dbaron@public.cloak)
57. # [09:22] * Joins: arronei (~arronei@public.cloak)
58. # [09:22] <TabAtkins_> ScribeNick: TabAtkins
59. # [09:22] <TabAtkins_> ScribeNick: TabAtkins_
60. # [09:22] * Joins: divya (~Adium@public.cloak)
61. # [09:23] * Joins: rhauck (~Adium@public.cloak)
62. # [09:23] <TabAtkins_> Topic: Relationship with html and css wg
63. # [09:23] * divya wonders where is the common TPAC channel is
64. # [09:23] <TabAtkins_> glazou: We still have no definition of what a scoped stylesheet is in CSS.
65. # [09:23] * Joins: mgylling (~mgylling@public.cloak)
66. # [09:23] <TabAtkins_> TabAtkins: fantasai and I will take care of that next month.
67. # [09:23] * plh will join at 9:30am with Paul Cotton to talk about html
68. # [09:23] <TabAtkins_> glazou: Also HTML added new selectors, etc.
69. # [09:24] <plh> (ie in 10 minutes)
70. # [09:24] * Joins: Reinaldo (~Reinaldo@public.irc.w3.org)
71. # [09:24] <TabAtkins_> glazou: PLH is also concerned about the TTA specs.
72. # [09:24] <TabAtkins_> glazou: The length of time they're taking.
73. # [09:24] * Joins: kensaku_ (~kensaku@public.cloak)
74. # [09:24] <TabAtkins_> glazou: I tried to say that they were complex specs.
75. # [09:24] <TabAtkins_> glazou: But they're already well interoperable.
76. # [09:24] * plh will be in the css room at 9:30 for one agenda item
77. # [09:24] * plh will come back after
78. # [09:24] <TabAtkins_> Topic: Agenda
79. # [09:25] * plh oop,s wrong channel
80. # [09:25] <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0304.html
81. # [09:25] <TabAtkins_> stearns: First issue is box generation.
82. # [09:25] <TabAtkins_> stearns: I posted how I think this issue should be handled in the spec.
83. # [09:25] <TabAtkins_> stearns: I don't think box generation is required for CSS regions.
84. # [09:25] <TabAtkins_> stearns: The issue is how to handle more content than will fit in a fixed region chain.
85. # [09:25] <TabAtkins_> stearns: We've added auto-height regions and the regions processing model to address this.
86. # [09:26] <TabAtkins_> stearns: So handling more content in a region is the same as in any other element.
87. # [09:26] <TabAtkins_> stearns: So I'd liketo close this issue.
88. # [09:26] * Joins: kazutaka (~yamamoto_kazutaka@public.cloak)
89. # [09:26] * Joins: lmclister (~lmclister@public.irc.w3.org)
90. # [09:26] <TabAtkins_> howcome: Examples?
91. # [09:26] * Joins: dino (~dino@public.cloak)
92. # [09:26] <TabAtkins_> stearns: The very first example in the spec has an example - the last region is auto height and will just take the rest of the flow.
93. # [09:26] <TabAtkins_> howcome: What about pagination?
94. # [09:27] <TabAtkins_> stearns: No effect on printing - it'll break across pages just like a normal element.
95. # [09:27] * Joins: kawabata (~kawabata@public.cloak)
96. # [09:27] <TabAtkins_> stearns: I got one response on the list from Anton saying it was reasonable.
97. # [09:28] <TabAtkins_> howcome: What dimensions does it expand?
98. # [09:28] <TabAtkins_> stearns: Same as an auto-height div.
99. # [09:28] <TabAtkins_> stearns: The email goes into what you can do witht he last region - you can make it auto height, scrollable, overflow:visible; everything you can do with a normal element.
100. # [09:29] * Joins: sakih (~sakih@public.cloak)
101. # [09:29] <TabAtkins_> TabAtkins_: I'm satisfied that this concludes the issue - the last region in a chain is no longer restricted, and you can do everything you can do with a normal element.
102. # [09:29] * Joins: yamaday (~yamaday@public.cloak)
103. # [09:29] <TabAtkins_> stearns: The issue as stated is that region chains can't handle a varaible amount of content. At the time the issue was raised, this was true. It's no longer.
104. # [09:30] <TabAtkins_> stearns: We could close this issue and let you raise further issues.
105. # [09:30] <TabAtkins_> fantasai: Can you have a region in the middle of the chain that's auto-height with a max-height, where it overflows to the next region in the chain?
106. # [09:30] <TabAtkins_> stearns: Yes, that's what the processing model now addresses.
107. # [09:30] * Joins: lstorset (~lastorset@public.cloak)
108. # [09:31] * sakih is now known as sakkuru
109. # [09:31] <TabAtkins_> RESOLVED: Close issue 15186 in Regions, concerning handling arbitrary amounts of content in a region chain.
110. # [09:32] <TabAtkins_> Rossen: can you swap css3-ui with something in the afternoon? I'm waiting for Tantek and Sylvain.
111. # [09:32] <yamaday> join #css
112. # [09:32] * hober yamaday: it worked!
113. # [09:33] * divya notifies interested parties of #tpac on irc.w3.org
114. # [09:34] * Joins: vhardy_ (~vhardy@public.cloak)
115. # [09:35] * Quits: Liam|XMLCore (liam@public.cloak) (Ping timeout: 60 seconds)
116. # [09:35] <TabAtkins_> Topic: HTML & CSS
117. # [09:35] <TabAtkins_> plh: HTML plans to move to CR by the end of the year.
118. # [09:35] <TabAtkins_> plh: So if there are any concersn from the CSSWG, I'd like to get it now.
119. # [09:35] <TabAtkins_> plh: Are there any issues from the CSSWG?
120. # [09:35] <TabAtkins_> glazou: I have three issues.
121. # [09:35] <TabAtkins_> glazou: The first is organization.
122. # [09:36] <TabAtkins_> glazou: The liaison between html and css - there has been none.
123. # [09:36] <TabAtkins_> glazou: The HTML spec concerns bits of CSS related to scoped stylesheets and selectors which were never discussed with us.
124. # [09:36] <TabAtkins_> glazou: I call that a big issue, since the htmlwg charter contains a liaison with us.
125. # [09:36] <TabAtkins_> glazou: Don't care what side the problem lies on, but it needs to be solved.
126. # [09:36] <fantasai> s/liaison/mandatory liaison/
127. # [09:36] <TabAtkins_> glazou: Second problem is technical.
128. # [09:36] <TabAtkins_> glazou: The html spec contains scoped stylesheets.
129. # [09:37] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 20 seconds)
130. # [09:37] <TabAtkins_> glazou: There's a grammar for scoped stylesheets in html, but we don't ahve a formal definition of how they'll work in CSS.
131. # [09:37] <TabAtkins_> glazou: There's no material the html spec can reference normatively.
132. # [09:37] <TabAtkins_> glazou: Third point is about CSS pseudoclasses.
133. # [09:38] <TabAtkins_> glazou: There are pseudoclasses inthe HTML spec - some are related to pseudos in css3-ui, but we never had a joint group or submission saying "we plan to include things that are in your charter in our spec, how can we do that, is that correct, etc."
134. # [09:38] <TabAtkins_> glazou: So it seems to me the process between the two WGs are completely broken.
135. # [09:38] <TabAtkins_> glazou: We dont' have these issues with the SVGWG - we work together great.
136. # [09:38] <TabAtkins_> glazou: So we have two things in the HTML spec that should be defined on our side.
137. # [09:39] <dbaron> TabAtkins: On selectors, we've either defined everything or HTML is just defining the host language part of it
138. # [09:39] <dbaron> TabAtkins: ... in cases where things are to be defined by the host language
139. # [09:39] * Joins: vhardy__ (~uid7483@public.cloak)
140. # [09:39] <TabAtkins_> plh: I like to understand if other people in the CSSWG share your opinions.
141. # [09:40] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
142. # [09:40] * Joins: mjs (~mjs@public.cloak)
143. # [09:40] <TabAtkins_> plh: And some of the CSSWG is in the HTMLWG, so if there's no liaison, I wonder what's oging on.
144. # [09:40] <TabAtkins_> dbaron: We've been through the form control stuff before, but I agree with Tab that there's no problem there.
145. # [09:40] <mjs> q+
146. # [09:40] * Zakim sees mjs on the speaker queue
147. # [09:41] <TabAtkins_> dbaron: I don't think the <style scoped> stuff is defined well anywhere yet, or if it reflects quite what our idea of how it will work is.
148. # [09:41] <stearns> TabAtkins_: Me will define
149. # [09:41] <TabAtkins_> plh: Is <style scoped> handled properly in HTML?
150. # [09:41] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
151. # [09:42] <TabAtkins_> fantasai: First thing is how selectors are scoped.
152. # [09:42] <TabAtkins_> fantasai: Second is a mechanism to change how they're scoped.
153. # [09:42] <franremy> (just a note: maybe we also need to speak about shadow dom and its interaction with CSS, those specs also contain quite a bite of CSS)
154. # [09:42] <TabAtkins_> fantasai: Third is howt he cascade is scoped.
155. # [09:42] <TabAtkins_> fantasai: The fourth is how globally scoped things like @font-face are handled.
156. # [09:42] * Joins: Norbert (~Norbert@public.cloak)
157. # [09:43] * Joins: yamaday (~yamaday@public.cloak)
158. # [09:43] <TabAtkins_> fantasai: So there's four aspects of this. We have a definition for the first, and Tab and I are planning to work on a the third.
159. # [09:43] <TabAtkins_> fantasai: Dunno about the second and fourth.
160. # [09:43] * Joins: Liam|XMLCore (liam@public.cloak)
161. # [09:43] * Joins: sakkuru_ (~sakih@public.cloak)
162. # [09:43] <TabAtkins_> TabAtkins_: The fourth is defined in hTML now - Boris got it fixed.
163. # [09:43] <TabAtkins_> fantasai: It doesn't matter if the HTMLWG editor is in the room or not, if they aren't bringing things up to us for review, etc.
164. # [09:44] * Quits: sakkuru (~sakih@public.cloak) (Ping timeout: 20 seconds)
165. # [09:44] <TabAtkins_> dbaron: I think we know about this - we don't need a formal email asking us to review it.
166. # [09:45] <fantasai> dbaron: The interesting question is, is there anything else we're not aware of.
167. # [09:45] <glazou> Zakim, ack mjs
168. # [09:45] <Zakim> I see no one on the speaker queue
169. # [09:46] <dbaron> dbaron: I don't think we need a formal email to inform us of something that we've discussed multiple times that we haven't received a formal email about.
170. # [09:46] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 20 seconds)
171. # [09:46] * Joins: plh (plehegar@public.cloak)
172. # [09:46] <glazou> glazou: I think we do formal link between groups
173. # [09:46] <plh> q?
174. # [09:46] * Zakim sees no one on the speaker queue
175. # [09:46] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
176. # [09:46] <glazou> mjs: this is first time I hear about these issues
177. # [09:46] <glazou> glazou: no
178. # [09:47] <fantasai> glazou: I sent them as LC comments during the vote
179. # [09:47] <fantasai> glazou: Never got a reply
180. # [09:47] <plh> q+ PaulCotton
181. # [09:47] * Zakim sees PaulCotton on the speaker queue
182. # [09:47] <fantasai> plinss: We sent comments last year as a WG, and the bug was closed WONTFIX by hixie
183. # [09:47] <fantasai> mjs: We have a clear process for escalating issues
184. # [09:48] <fantasai> mjs: We love technical input, but don't go out of our way to solicit it
185. # [09:48] <fantasai> mjs invites CSSWG members to participate in HTMLWG meetings at TPAC
186. # [09:49] <fantasai> mjs: Recently had change of editors, trying to be more open to input
187. # [09:49] <glazou> Zakim, ack PaulCotton
188. # [09:49] <Zakim> I see no one on the speaker queue
189. # [09:50] <fantasai> PaulCotton: Want to be more factual here. What are the bug numbers raised on these issues?
190. # [09:50] <fantasai> PaulCotton: What are the comments that were made for LC?
191. # [09:50] <glazou> Zakim, q+
192. # [09:50] <Zakim> I see glazou on the speaker queue
193. # [09:51] <fantasai> PaulCotton: If there weren't issues raised as tracker issues, we don't pay attention to them.
194. # [09:51] <fantasai> glazou: We discussed on HCG these issues
195. # [09:51] <dbaron> plinss: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13693
196. # [09:52] <fantasai> TabAtkins: Raised as email comments; you're not allowed to ignore those just because bug wasn't filed
197. # [09:52] <fantasai> glazou: All the comments, through various channels were dismissed.
198. # [09:53] * Parts: yamaday (~yamaday@public.cloak) (yamaday)
199. # [09:53] <dbaron> fantasai: I think there are three issues, 2 technical. I think selectors issue already addressed by selectors4.
200. # [09:53] <dbaron> mjs: for record, bug doesn't mention scoped style sheets at all
201. # [09:53] * Joins: yamaday (~yamaday@public.cloak)
202. # [09:53] <dbaron> glazou: Then HTML is referencing a non-normative document (FPWD)
203. # [09:53] <dbaron> plh: Where do you think selectors4 will be in 2014?
204. # [09:53] <dbaron> fantasai: Probably last call or CR.
205. # [09:54] <dbaron> glazou: maybe, maybe not
206. # [09:54] <dbaron> fantasai: So that problem is solved as long as HTML correctly referencing selectors4.
207. # [09:54] <dbaron> fantasai: Second issue is about scoped style, 4 sub-issues.
208. # [09:54] <dbaron> ted: Already at-risk for HTML5.
209. # [09:54] <dbaron> plh: I would ... the HTML WG to drop the feature and put in HTML.next.
210. # [09:54] <dbaron> plh: Sounds too risky to keep in HTML 5.0.
211. # [09:55] <dbaron> mjs: I'd like a record of the four issues.
212. # [09:55] <dbaron> TabAtkins, fantasai: in minutes
213. # [09:55] <plh> s/.../advocate/
214. # [09:55] <dbaron> TabAtkins, fantasai: We should have a draft in the next month.
215. # [09:55] <dbaron> fantasai: This is a complicated feature that ought to have a stable definition, not one writen 2 months before CR.
216. # [09:55] <dbaron> dirk: ???
217. # [09:55] <dbaron> fantasai: Third issue is the process issue.
218. # [09:56] <dbaron> fantasai: Basically what's happening is that the CSS WG would like the HTML WG to take some initiative to contact us when defining things in the scope of our charter.
219. # [09:56] <krit> s/???/Since we don't have one implementation, it may should not be in HTML5.0/
220. # [09:56] <dbaron> fantasai: Whether HTML WG does this by assigning a task to common members or some other process. Fact is it hasn't happened.
221. # [09:56] <dbaron> glazou: or an email
222. # [09:56] <dbaron> PaulCotton: So in the last 2 years I've tried several times to get HTML WG to pay attention to progression of docs in other WGs.
223. # [09:57] <dbaron> PaulCotton: As a co-chair it's pretty frustrating. I try to solicit input from HTML WG and get nothing.
224. # [09:57] <dbaron> PaulCotton: Not even from members of other WG.
225. # [09:57] <dbaron> q+
226. # [09:57] * Zakim sees glazou, dbaron on the speaker queue
227. # [09:57] <dbaron> PaulCotton: So the ??? hasn't worked in the past.
228. # [09:57] <glazou> Zakim, ack glazou
229. # [09:57] <Zakim> I see dbaron on the speaker queue
230. # [09:57] <dbaron> PaulCotton: I think we probably need somebody on point here.
231. # [09:57] <dbaron> PaulCotton: I think we need somebody to draw attention to these kinds of things.
232. # [09:57] <dbaron> PaulCotton: We have new editors now.
233. # [09:57] <glazou> Zakim, q+
234. # [09:57] <Zakim> I see dbaron, glazou on the speaker queue
235. # [09:57] <dbaron> PaulCotton: I think with new editors: bugs, interop problems, ... bring that to your attention.
236. # [09:58] <glazou> Zakim, ack dbaron
237. # [09:58] <Zakim> I see glazou on the speaker queue
238. # [09:58] <dbaron> PaulCotton: I think the other route, bringing your (CSS) documents to attention of HTML WG isn't going to work.
239. # [09:58] * hober thinks he can count the number of html5 editors who are in the csswg on one finger...
240. # [09:58] <glazou> Zakim, q+ fantasai
241. # [09:58] <Zakim> I see glazou, fantasai on the speaker queue
242. # [09:58] <glazou> Zakim, q+ GlennAdams
243. # [09:58] <Zakim> I see glazou, fantasai, GlennAdams on the speaker queue
244. # [09:58] <TabAtkins_> dbaron: You probably heard me say this before, but I'm not a big fan of trying to make thing WG-to-WG communication.
245. # [09:58] <fantasai> dbaron: You've probably heard me say this before, but I'm not a big fan of trying to make things WG-WG communication
246. # [09:58] <TabAtkins_> dbaron: I think there is a lot of value in giving notice to WGs about things that are related.
247. # [09:58] <TabAtkins_> dbaron: I don't see that the response needs to be from the WG as a whole.
248. # [09:59] <TabAtkins_> dbaron: If there's consensus about a response, fine, it can be from the WG as a whole, but I don't worry about the whole-WG response.
249. # [09:59] <glazou> Zakim, ack me
250. # [09:59] <Zakim> I see fantasai, GlennAdams on the speaker queue
251. # [09:59] <TabAtkins_> glazou: Paul, you say you'd like someone in your WG to coordinate and give us feedback.
252. # [09:59] <TabAtkins_> glazou: I'd like the Chairs to do it. Taht's what we do - when SVG has something, Doug pings us. The chairs discuss things. It's informal, but it works well.
253. # [10:00] <TabAtkins_> hober: In CSS/SVG, we have the FXTF to help discuss issues.
254. # [10:00] <TabAtkins_> glazou: Even before that.
255. # [10:00] <TabAtkins_> glazou: It's not hard. It's just a matter of person-to-person email. It's doable.
256. # [10:00] <glazou> Zakim, ack fantasai
257. # [10:00] <Zakim> I see GlennAdams on the speaker queue
258. # [10:00] <TabAtkins_> fantasai: With regards to feedback on oru specs, our resp. is to ifnorm you of spec's we're writing that might affect HTML and it's interaction.
259. # [10:00] <TabAtkins_> fantasai: I think we've done that, but please point out if we need to improve.
260. # [10:01] <mjs> q+
261. # [10:01] * Zakim sees GlennAdams, mjs on the speaker queue
262. # [10:01] <TabAtkins_> fantasai: As for responses from the WG, doesn't matter. Individual WG members were informed, had the ability to respond, but it hasn't happened.
263. # [10:01] <TabAtkins_> fantasai: The members of the CSSWG that aren't in the HTMLWG haven't been informed about thing sin HTML that affect CSS.
264. # [10:01] <glazou> Zakim, ack GlennAdams
265. # [10:01] <Zakim> I see mjs on the speaker queue
266. # [10:01] <TabAtkins_> fantasai: In particular, HTML defines things that are fundamentally not in their charter.
267. # [10:01] <TabAtkins_> fantasai: Which may be a bit over the line.
268. # [10:02] * Joins: glenn (~gadams@public.cloak)
269. # [10:02] <glazou> Zakim, q+ PaulCotton
270. # [10:02] <Zakim> I see mjs, PaulCotton on the speaker queue
271. # [10:02] <TabAtkins_> glenn: In that regard, Hixie has been communicating with me about things that affect the CSSOM.
272. # [10:02] <glazou> Zakim, ack mjs
273. # [10:02] <Zakim> I see PaulCotton on the speaker queue
274. # [10:02] <TabAtkins_> mjs: Can someone give me an example of a time that the CSSWG has informed the HTMLWG about a relevant spec change.
275. # [10:02] <fantasai> TabAtkins_: element function in images spec, wanted to integrate with HTML in a particular way
276. # [10:03] <fantasai> TabAtkins_: I sent an email into HTMLWG and hixie fixed it for me
277. # [10:03] <fantasai> TabAtkins_: Done similar things with WebApps
278. # [10:03] <glazou> Zakim, ack PaulCotton
279. # [10:03] <Zakim> I see no one on the speaker queue
280. # [10:03] <fantasai> PaulCotton: Hixie is no longer an editor in the HTMLWG
281. # [10:03] <hober> I believe TabAtkins was referring to https://www.w3.org/Bugs/Public/show_bug.cgi?id=14028
282. # [10:04] * Joins: SteveZ (~chatzilla@public.cloak)
283. # [10:04] <fantasai> PaulCotton: If you want to communicate wrt HTML5 spec, it's no longer hixie.
284. # [10:04] <fantasai> PaulCotton: When wanting changes with CR, need to communicate with current editors, not hixie
285. # [10:04] <glazou> Zakim, q+
286. # [10:04] <Zakim> I see glazou on the speaker queue
287. # [10:04] <fantasai> q+
288. # [10:04] * Zakim sees glazou, fantasai on the speaker queue
289. # [10:05] <fantasai> PaulCotton: Question was what happens to changes hixie makes
290. # [10:05] <fantasai> PaulCotton: Our editors are triaging all of those changes
291. # [10:05] <fantasai> PaulCotton: For changes that go into 5.1, we're previewing in WG
292. # [10:05] <fantasai> PaulCotton: But editors in WG are about to produce CR drafts
293. # [10:05] <fantasai> PaulCotton: Those CR drafts will be only changes that are interoperability-based
294. # [10:05] <fantasai> PaulCotton: It's possible that change from WHATWG would make it into 5.1
295. # [10:05] <fantasai> PaulCotton: Also possible that if it's an interop problem, it would get into 5.0
296. # [10:06] <fantasai> PaulCotton: But not guaranteed
297. # [10:06] <glazou> Zakim, ack me
298. # [10:06] <Zakim> I see fantasai on the speaker queue
299. # [10:06] <fantasai> glazou: Would like us to use HTCG a bit more for communication. You are three co-chairs, but rarely attend the calls
300. # [10:07] <fantasai> glazou: I've been sending status reports for CSSWG even when I did not attend, and these include changes to our documents. Never triggered a reaction from you.
301. # [10:07] <fantasai> glazou: When I said in HTCG that there were problems wrt scoped styles, there was no reaction from you.
302. # [10:07] <fantasai> glazou: We have a tool in our hands.
303. # [10:07] <fantasai> mjs: I find the coordination calls useless
304. # [10:07] <fantasai> glazou: Then let's do that by email
305. # [10:08] <fantasai> [HTCG doesn't have regular calls any more, just as needed]
306. # [10:08] <dbaron> Present: (at table) Dean Jackson, Glenn Adams, Philippe Le Hegaret, Anton Prowse, Francois Remy, Rossen Atanassov, Simon Sapin, Lea Verou, Divya Manian, Tab Atkins, Luke MacPherson, Alan Stearns, Steve Zilles, Dirk Schultze, Bert Bos, Leif Arne Storset, Vincent Hardy, Paul Cotton, Daniel Glazman, Ted O'Connor, Håkon Lie, David Baron, Elika Etemad, Aaron Eicholz, Taichi Kawabata, Kazutaka Yamamoto, Koji Ishii, Peter Linss, Maciej Stachowiak
307. # [10:08] <fantasai> glazou: We've had this communication channel for years; it hasn't been used.
308. # [10:08] <glazou> Zakim, ack fantasai
309. # [10:08] <Zakim> I see no one on the speaker queue
310. # [10:08] <TabAtkins_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16169
311. # [10:09] <TabAtkins_> fantasai: Maciej wanted examples of us contacting the HTMLWG about changes affecting them.
312. # [10:09] <dbaron> Present (in back row): Rik Cabanier, ???, ???, Rebecca Hauck, ???, Israel Noto Garcia, Jet Villegas, ???, ???
313. # [10:09] <TabAtkins_> fantasai: First, we don't include things within the scope of the HTML charter within our specs.
314. # [10:09] * Joins: florianr (~yaaic@public.cloak)
315. # [10:09] <TabAtkins_> fantasai: But for things where we think the HTMLWG could do a good review (such as Image Values or Selectors), we have explicitly pinged the HTMLWG for review.
316. # [10:10] <stearns> dbaron: some ???s: Israel Noto Garcia, Laurence Mclister, Rik Cabanier
317. # [10:10] <fantasai> mjs: How would you like us to inform you of changes we need in CSS? Filing a bug?
318. # [10:10] <fantasai> TabAtkins: Send an email to www-style.
319. # [10:11] <fantasai> mjs asks for example
320. # [10:11] <fantasai> TabAtkins: The bugs I filed against HTML are examples
321. # [10:11] <dbaron> mjs (above): Can you point to an email you've sent that's an example of what you'd consider sufficient notice to you?
322. # [10:11] <TabAtkins_> fantasai: Hixie has sent us emails asking for specific changes in CSS specs, and that's exactly how it should be handled.
323. # [10:11] <dbaron> fantasai: Hixie sent us some emails asking for changis in CSS specs; those were exactly how it should be handled.
324. # [10:12] <plh> q?
325. # [10:12] * Zakim sees no one on the speaker queue
326. # [10:12] <dbaron> fantasai: What wasn't handled was saying that we drafted a new CSS feature and put it in HTML5 spec.
327. # [10:12] <TabAtkins_> fantasai: What wasn't handled was something informing us of some of the CSS features in HTML being drafted at all. ^_^
328. # [10:12] * dbaron lets TabAtkins continue minuting
329. # [10:12] <TabAtkins_> mjs: So what do you need to continue technically to resolve any issues in HTML?
330. # [10:12] <plh> q+
331. # [10:12] * Zakim sees plh on the speaker queue
332. # [10:13] <TabAtkins_> mjs: As far as I know, all we've gotten so far in the HTMLWG about style scoped is that it's undefined, from Glazou.
333. # [10:13] * Joins: jet (~jet@public.cloak)
334. # [10:13] <TabAtkins_> mjs: But today we have four things being about it.
335. # [10:13] <TabAtkins_> TabAtkins_: They're four ways of saying a specific thing is undefined.
336. # [10:13] <TabAtkins_> glazou: Scoped stylesheets will be a major way to copypaste stylesheets. There are multiple deep technical issues to solve about these. It won't happen today.
337. # [10:14] <TabAtkins_> glazou: My take is that it's so undefined right now, and there's so much on our radar, it's at risk, but you should drop it for now.
338. # [10:14] <TabAtkins_> glenn: Are there two interop impls?
339. # [10:14] <TabAtkins_> TabAtkins_: No - we've specifically held back our impl because it's not interop with how we know we want it to act.
340. # [10:14] <hober> So, has someone filed a "Drop <style scoped>" bug?
341. # [10:14] <TabAtkins_> glazou: It's so undefined, and will take long enough to do so, that it should be dropped.
342. # [10:15] <TabAtkins_> mjs: If best solution turns out that it shoudl be dropped, that's fine.
343. # [10:15] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
344. # [10:15] <TabAtkins_> mjs: But we need a bug and to be informed about this.
345. # [10:16] <TabAtkins_> mjs: I've heard several rapid-fire problems listed today, but we need those details to be brought to us.
346. # [10:16] <fantasai> TabAtkins_: The original problem we're bringing up is that nobody told us about it, or asked us to define it. Just now picking it up because we have to
347. # [10:16] <fantasai> TabAtkins_: But even within HTMLWG, ppl know that it's not well-enough defined to be implemented right now. bzbarsky has given feedback; Chrome is holding back implementation because it doesn't match what we want to do
348. # [10:17] <fantasai> TabAtkins_: The problem is well-known within HTMLWG
349. # [10:17] <plh> q+ PaulCotton
350. # [10:17] * Zakim sees plh, PaulCotton on the speaker queue
351. # [10:17] <fantasai> glazou: One concrete example I said is specificity of selectors, don't know technical solution we choose, need discussion to happen, but will drastically impact solution. Not a 10-minutes discussion
352. # [10:17] <fantasai> glazou: Need to find compromise that satisfies everyone.
353. # [10:18] * Joins: tomoyuki (~tshimizu3@public.cloak)
354. # [10:18] <fantasai> glazou: And it's on our side, not on yours. It's about how the cascade works. Not in the HTML spec.
355. # [10:18] <fantasai> glazou: Am I completely mistaken or what?
356. # [10:19] * Quits: mjs (~mjs@public.cloak) (mjs)
357. # [10:19] * Quits: Liam|XMLCore (liam@public.cloak) (Ping timeout: 60 seconds)
358. # [10:19] <TabAtkins_> plh: It seems to me that we have information on the style scoped about whether to keep it or not.
359. # [10:19] <franremy> q: can't we replace the scoped attribute with a :scope-root pseudo-class so that it doesn't have to be defined in HTML at all?
360. # [10:19] <TabAtkins_> mjs: I don't think we have. You guys have told us multiple rapid-fire problems, but they haven't been listed.
361. # [10:19] <plh> q?
362. # [10:19] * Zakim sees plh, PaulCotton on the speaker queue
363. # [10:19] <dbaron> q+
364. # [10:19] * Zakim sees plh, PaulCotton, dbaron on the speaker queue
365. # [10:19] <plh> ack plh
366. # [10:19] * Zakim sees PaulCotton, dbaron on the speaker queue
367. # [10:19] <TabAtkins_> TabAtkins_: they're all variants of "it's undefined". The specifics dont' matter. You've known it was undefined since we told you a year ago.
368. # [10:19] <TabAtkins_> mjs: Okay, so what should we do specifically?
369. # [10:20] <TabAtkins_> glazou: Drop it.
370. # [10:20] <plh> q?
371. # [10:20] * Zakim sees PaulCotton, dbaron on the speaker queue
372. # [10:20] <TabAtkins_> mjs: Give us that feedback specifically. Send it in.
373. # [10:20] <TabAtkins_> mjs: Please submit a comment to the HTMLWG saying that and giving rationale.
374. # [10:20] <TabAtkins_> glazou: I've done that multiple times.
375. # [10:20] <TabAtkins_> mjs: I looked up your comments, and you didn't actually say that.
376. # [10:21] <TabAtkins_> glazou: PLH, do we really discuss inter-WG things via bugs only?
377. # [10:21] <TabAtkins_> glazou: I don't understand why you need more input from us.
378. # [10:22] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
379. # [10:22] <TabAtkins_> PaulCotton: I asked for exact comments. You pointed to a bug. It was closed, you didn't reopen.
380. # [10:22] * Joins: evanli (~androirc@public.cloak)
381. # [10:23] <TabAtkins_> mjs: The HTMLWG has a process. If you engage in it, we'll respond. But berating us won't solve a problem. If the problem is that it's underdefined and won't be solved in time, file a bug.
382. # [10:23] <TabAtkins_> mjs: If you're unwilling to engage in our process, then I won't help you.
383. # [10:23] * dbaron q?
384. # [10:23] * Zakim sees PaulCotton, dbaron on the speaker queue
385. # [10:23] * fantasai doesn't understand why hober doesn't just file a bug so we can get on with it
386. # [10:23] <plh> --> http://lists.w3.org/Archives/Public/public-html/2012May/0080.html email from Tab regarding scoped
387. # [10:23] <dbaron> ack PaulCotton
388. # [10:23] * Zakim sees dbaron on the speaker queue
389. # [10:24] <TabAtkins_> PaulCotton: Idon't quite agree with Philippe about ???...
390. # [10:24] <TabAtkins_> PaulCotton: This spec will be in CR for 18 months at least.
391. # [10:24] * Quits: kensaku_ (~kensaku@public.cloak) (Client closed connection)
392. # [10:24] * Quits: vhardy_ (~vhardy@public.cloak) (Ping timeout: 20 seconds)
393. # [10:24] * vhardy__ is now known as vhardy_
394. # [10:24] <TabAtkins_> PaulCotton: I think that marking it as at-risk with this evidence, is probably the right status.
395. # [10:24] <divya> s/Philippe/macej
396. # [10:24] <TabAtkins_> dbaron: I've been on the queue for 5 minutes to say that I disagree that dropping is the right thing. I'd rather see it stay for now.
397. # [10:25] <TabAtkins_> dbaron: If you want a WG opinion, we need to take the time for that discussion. But I don't think right now is the right time for that discussion.
398. # [10:25] <TabAtkins_> glenn: Agree. At-risk is easier than dropping and restoring.
399. # [10:25] <TabAtkins_> mjs: It's at-risk right now. We can enhance our at-risk list with annotations for reasoning.
400. # [10:26] <TabAtkins_> mjs: Getting dependencies right, getting implementors to implement, define it.
401. # [10:26] * fantasai doesn't think the "at risk" list is the right place for "things we think are cool but don't have time to define correctly"
402. # [10:26] * fantasai also doesn't understand why it's a problem to drop it here, given it'll still be in the HTML.next drafts that hixie edits
403. # [10:26] * Joins: liam (liam@public.cloak)
404. # [10:28] <krit> Zakim, q+
405. # [10:28] <Zakim> I see dbaron, krit on the speaker queue
406. # [10:28] * dbaron q-
407. # [10:28] * Zakim sees krit on the speaker queue
408. # [10:28] <TabAtkins_> plh: Other issue is Selectors 4 having some of the HTML selectors.
409. # [10:28] <plh> --> http://dev.w3.org/html5/spec/single-page.html#pseudo-classes
410. # [10:28] <TabAtkins_> TabAtkins_: The ones in HTML right now are all just the host-language stuff. The real new things are in WebVTT.
411. # [10:29] * fantasai is willing to bet that Selectors 4 will get to CR before HTML5 has enough testcases to actually test the spec
412. # [10:29] <TabAtkins_> mjs: WebVTT is no longer a HTMLWG deliverable. It's in a CG.
413. # [10:29] <TabAtkins_> glazou: This is a quite heated discussion, I agree. But we'd love to help the WG witht he HTML spec. We'd love to be pinged when it's on our scope.
414. # [10:29] * Joins: mjs (~mjs@public.cloak)
415. # [10:29] <Bert> q+ to mention another (some day) coord. issue: <DETAILS>
416. # [10:29] * Zakim sees krit, Bert on the speaker queue
417. # [10:30] <TabAtkins_> hober: Right now we're trying to remove/drop things, not add.
418. # [10:30] <TabAtkins_> plh: But in HTML.next, if ever there is something new added, tell the CSSWG.
419. # [10:30] * Quits: mjs (~mjs@public.cloak) (mjs)
420. # [10:30] <TabAtkins_> PaulCotton: The way we're pulling from WHATWG to HTML5.1, the triage team should probably check for CSS-specific things and send an email to the CSSWG.
421. # [10:31] <TabAtkins_> mjs: In the past when stuff got put into the spec, I'll be honest and say it was largely editor recalcitrance.
422. # [10:31] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 20 seconds)
423. # [10:31] * Joins: Rossen (~Rossen@public.cloak)
424. # [10:32] <TabAtkins_> Bert: About a year ago I sent a personal note that I think there's a better way to define the <details> element that makes it easier to style in pure CSS.
425. # [10:32] <TabAtkins_> plh: Feel free to bring that up in our meeting Thu/Fri.
426. # [10:32] * Quits: divya (~Adium@public.cloak) ("Leaving.")
427. # [10:32] <dbaron> break-duration: calc(15 * 60s)
428. # [10:33] * Quits: Reinaldo (~Reinaldo@public.irc.w3.org) (Ping timeout: 20 seconds)
429. # [10:33] <Bert> q-
430. # [10:33] * Zakim sees krit on the speaker queue
431. # [10:33] <TabAtkins_> zakim, ack krit
432. # [10:33] <Zakim> I see no one on the speaker queue
433. # [10:34] * Joins: tomoyuki (~tshimizu3@public.cloak)
434. # [10:35] * Quits: lmclister (~lmclister@public.irc.w3.org) (Ping timeout: 20 seconds)
435. # [10:35] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
436. # [10:35] * Quits: lstorset (~lastorset@public.cloak) (Ping timeout: 20 seconds)
437. # [10:35] * Quits: Norbert (~Norbert@public.irc.w3.org) (Ping timeout: 20 seconds)
438. # [10:36] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 20 seconds)
439. # [10:37] * Quits: tomoyuki (~tshimizu3@public.cloak) (Ping timeout: 20 seconds)
440. # [10:38] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
441. # [10:38] * Joins: yaso (~yaso@public.cloak)
442. # [10:39] * Joins: rubylin (~rubylin@public.cloak)
443. # [10:40] * Joins: tomoyuki (~tshimizu3@public.cloak)
444. # [10:42] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
445. # [10:44] * Joins: vhardy__ (~vhardy@public.cloak)
446. # [10:46] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
447. # [10:48] * Quits: sakkuru_ (~sakih@public.cloak) (Ping timeout: 20 seconds)
448. # [10:50] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
449. # [10:50] * Joins: yamaday (~yamaday@public.cloak)
450. # [10:52] * Quits: yamaday (~yamaday@public.cloak) (Client closed connection)
451. # [10:52] * Joins: yamaday (~yamaday@public.cloak)
452. # [10:52] * Quits: yaso (~yaso@public.cloak) (yaso)
453. # [10:54] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
454. # [10:56] * Joins: tomoyuki (~tshimizu3@public.cloak)
455. # [10:56] <yamaday> aaaaaaaaaaa
456. # [10:58] * Quits: JohnJansen (~JohnJansen@public.irc.w3.org) ("Page closed")
457. # [10:58] * Joins: John_Jansen (~JohnJansen@public.cloak)
458. # [10:59] * Quits: vhardy__ (~vhardy@public.cloak) (vhardy__)
459. # [11:00] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 20 seconds)
460. # [11:00] * Quits: yamaday (~yamaday@public.cloak) (Ping timeout: 20 seconds)
461. # [11:01] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) (Ping timeout: 20 seconds)
462. # [11:01] * Quits: John_Jansen (~JohnJansen@public.cloak) ("")
463. # [11:01] * Joins: rhauck (~Adium@public.cloak)
464. # [11:03] * Joins: JohnJansen (~JohnJansen@public.cloak)
465. # [11:03] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
466. # [11:03] * Joins: yamaday (~yamaday@public.cloak)
467. # [11:04] * Joins: drublic (~drublic@public.cloak)
468. # [11:04] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 20 seconds)
469. # [11:06] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 20 seconds)
470. # [11:07] * Joins: lmclister (~lmclister@public.irc.w3.org)
471. # [11:07] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
472. # [11:08] * Joins: rhauck (~rhauck@public.irc.w3.org)
473. # [11:08] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
474. # [11:10] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
475. # [11:10] * Joins: yamaday (~yamaday@public.cloak)
476. # [11:12] * Joins: tomoyuki (~tshimizu3@public.cloak)
477. # [11:14] * Joins: mgylling (~mgylling@public.cloak)
478. # [11:16] * Joins: cabanier (~cabanier@public.cloak)
479. # [11:16] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
480. # [11:16] * Joins: mjs (~mjs@public.cloak)
481. # [11:16] <dbaron> </br>
482. # [11:17] <dbaron> Topic: Regions issues
483. # [11:17] <dbaron> Alan: 3 issues left
484. # [11:17] * Joins: divya (~Adium@public.cloak)
485. # [11:17] * sylvaing is now known as sylvaing_away
486. # [11:18] <TabAtkins_> stearns: The draft currently says that Regions create their own stacking contexts. There's an issue on the draft that perhaps we shouldn't do that, and allow them to be non-stacking.
487. # [11:18] * Quits: tomoyuki (~tshimizu3@public.cloak) (Client closed connection)
488. # [11:18] <TabAtkins_> stearns: My contention is that regions should behave more like the things that *do* create stacking contexts, like fixpos/flaots/etc, because we are taking content out of the flow and putting it somewhere else.
489. # [11:18] * Joins: Rossen (~Rossen@public.cloak)
490. # [11:18] <TabAtkins_> stearns: Same justification for those applies to Regions. Little case for interleaving content.
491. # [11:19] <TabAtkins_> dbaron: Floats actually create a pseudo-stacking context.
492. # [11:19] <TabAtkins_> antonp: I don't think authors like stacking contexts.
493. # [11:19] <TabAtkins_> hober: I think most authors don't know what a stacking context is, and when things interleave in weird ways, that's funky behavior.
494. # [11:19] <TabAtkins_> hober: Will probably result in performance issue, which we can avoid...
495. # [11:19] <TabAtkins_> hober: I don't think authors would interleave on purpose.
496. # [11:20] <TabAtkins_> antonp: The reason the funny painting model exists is because people had overflow they weren't expecting; floats and next paragraphs and etc.
497. # [11:20] <TabAtkins_> antonp: That's why text is painted after all background/borders/etc.
498. # [11:20] * Joins: Norbert_ (~Norbert@public.cloak)
499. # [11:20] <TabAtkins_> antonp: Makes overlaps less painful.
500. # [11:20] <TabAtkins_> antonp: So it was historically because there was a lot of overflow, and impls thought it was better to see content.
501. # [11:20] <TabAtkins_> dbaron: I'm not sure it was that logical of a process.
502. # [11:21] <TabAtkins_> dbaron: There's a decent chunk that was Hixie and I interpreting a vague chunk of the spec, and coming up with the one precise definition that satisfied it, then wrote tests and got impls, and that was that.
503. # [11:21] <TabAtkins_> dbaron: Never really learned how much of that was intentional.
504. # [11:21] <TabAtkins_> dbaron: The spec never quite said that the backgrounds of the next paragraph drew under the text of the next paragraph, but you could infer it from a rule about floats, which was similar.
505. # [11:22] <TabAtkins_> dbaron: The thing I'm slightly worried about is...
506. # [11:22] <TabAtkins_> dbaron: You're talking a region being a stacking context?
507. # [11:22] <TabAtkins_> dbaron: Each region?
508. # [11:22] <TabAtkins_> stearns: Each region is a context for the fragment of the flow in it.
509. # [11:23] <TabAtkins_> dbaron: My problem is when people put regions close to each other to give the illusion of continuous flow
510. # [11:23] <TabAtkins_> TabAtkins_: Like using them to make a "non-rectangular grid cell".
511. # [11:23] <TabAtkins_> dbaron: yeah. But I think there might be weird issues now.
512. # [11:23] <TabAtkins_> stearns: That's only a problem if they break outside of the bounds of the region.
513. # [11:23] <TabAtkins_> dbaron: Not necessarily rare, with text slightly overflowing, etc.
514. # [11:23] <TabAtkins_> dbaron: Don't have a strong opinion, but I'ma little worriedabout that case.
515. # [11:24] <TabAtkins_> stearns: I'm not really sure what to do about that case.
516. # [11:24] * Joins: rotsuya (~rotsuya@public.cloak)
517. # [11:24] <stearns> s/to do/to say/
518. # [11:24] * Joins: kensaku (~kensaku@public.cloak)
519. # [11:24] <TabAtkins_> Rossen: No real opinion...
520. # [11:24] <TabAtkins_> Rossen: From the pov of having valid use-cases for where it's really interesting to have interleaving, we struggled to find such a use-case.
521. # [11:25] <TabAtkins_> Rossen: The one David is bringing up is somewhat valid for the content being laid out between the regions themselves.
522. # [11:25] * Joins: sakkuru (~sakih@public.cloak)
523. # [11:25] * Joins: toms (~chatzilla@public.cloak)
524. # [11:25] <TabAtkins_> Rossen: It is more interesting to see how the rest of the content outside the regions interacts with the content inside.
525. # [11:25] * sylvaing_away is now known as sylvaing
526. # [11:25] <TabAtkins_> Rossen: This is why we'd prefer regions being their own stacking context.
527. # [11:25] <TabAtkins_> Rossen: So you don't have weird interleaving between parts of the regions.
528. # [11:25] * Joins: hsivonen (~hsivonen@public.cloak)
529. # [11:26] <TabAtkins_> antonp: I buy that point.
530. # [11:26] <TabAtkins_> antonp: I'm kinda thinking, you got stuff flowing down the left, you got regions on the right, and you're directing flows through each, and if you've got a long word on the left it'll interleave with what's on the right.
531. # [11:26] * Quits: florianr (~yaaic@public.cloak) ("")
532. # [11:26] <TabAtkins_> antonp: What about a pseudo-stacking context, so abspos doesn't have to deal with it?
533. # [11:27] * Quits: yamaday (~yamaday@public.cloak) (Client closed connection)
534. # [11:27] <TabAtkins_> TabAtkins_: I think that limiting abspos is actually an important part of it.
535. # [11:27] * Joins: yamaday (~yamaday@public.cloak)
536. # [11:28] <TabAtkins_> szilles: This seems a bit like the problems of composition in SVG - they introduced groups to denote what things are part of "the same thing" versus a different thing.
537. # [11:28] <TabAtkins_> szilles: Conceivably one could introduce a similar property that groups things like that.
538. # [11:28] <TabAtkins_> TabAtkins_: Like explicitly turning on stacking contexts without side effects?
539. # [11:29] <TabAtkins_> szilles: No, other way around. Declaring that some stacking contexts are part of a group, so within that group they can interact, but they're still shielded from the rest of the group.
540. # [11:29] <TabAtkins_> Rossen: To add to this, it becomes more apparent once you bring content that's not quite in the same document into regions.
541. # [11:29] <TabAtkins_> Rossen: Then you have content from separate documents that can interleave.
542. # [11:29] <TabAtkins_> TabAtkins_: You're talking about IE's addition that lets them flow iframes into a region flow?
543. # [11:29] * hober runs screaming from the room (re: region flow sourced from <iframe>)
544. # [11:30] <Bert> q+ to compare regions with columns
545. # [11:30] * Zakim sees Bert on the speaker queue
546. # [11:30] <TabAtkins_> Rossen: Yeah. You don't want an iframe to be interleaved with anything else.
547. # [11:30] <TabAtkins_> antonp: At the very least that says you want pseudo-stacking contexts. It doesnt' necessarily talk about abspos.
548. # [11:30] <TabAtkins_> antonp: abspos is a weird beast. But when people use it, they get frustrated that you can't choose where things are positioned from.
549. # [11:30] <TabAtkins_> antonp: By locking it into the region box, it seems you're taking away a little of the freedom they otherwise have.
550. # [11:31] <TabAtkins_> TabAtkins_: There's a workaround - flow the abspos into *another* region chain, and flow-from it somewhere outside higher in the document.
551. # [11:32] <TabAtkins_> Bert: That loses the auto position, though.
552. # [11:32] * Joins: tomoyuki (~tshimizu3@public.cloak)
553. # [11:32] <TabAtkins_> TabAtkins_: If you're usign the auto position, you probably don't need to worry about stacking context.
554. # [11:32] <TabAtkins_> Bert: Most of the time when I use regions, I started using columns, then found a weird case, and had to replace the columns with regions.
555. # [11:32] <TabAtkins_> Bert: That means that I'd like them to act like columns.
556. # [11:33] <TabAtkins_> glazou: [something about columns across pages, and how regions would work the same way maybe?]
557. # [11:33] <TabAtkins_> Bert: Point is that I'd like columns to act the same way as regions.
558. # [11:34] <TabAtkins_> stearns: So that's an argument for Steve's suggestion - the ability to group contexts together.
559. # [11:34] <TabAtkins_> dbaron: So you say that having flow-from on an element makes it a stackign context automatically?
560. # [11:34] <TabAtkins_> stearns: yes, that's part of the spec right now.
561. # [11:34] * Joins: yaso (~yaso@public.cloak)
562. # [11:35] <TabAtkins_> stearns: I have been arguing both sides of the issue with my teamf or months now, and I think I've come down on the side of stacking contexts.
563. # [11:35] <TabAtkins_> stearns: Possibly with a future mechanism to aggregate stacking contexts.
564. # [11:35] <TabAtkins_> TabAtkins_: I'm cool with that. I just don't want automatic grouping, from a performance standpoint.
565. # [11:36] <TabAtkins_> stearns: Hyatt's doing some work with identical regions, which might be relevant there.
566. # [11:36] <TabAtkins_> stearns: So, are there any objections to keeping what the spec currently says?
567. # [11:36] <TabAtkins_> stearns: (i was arguing for the opposite position in my team, and I lost the argument)
568. # [11:37] <TabAtkins_> Bert: It doesn't sound quite right - it's like an implicit relpos, which limits what you can do with abspos.
569. # [11:37] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
570. # [11:38] <TabAtkins_> TabAtkins_: I think that there are enough implicit positioning containments already that we can argue this is a general limitation of *abspos*, not of any individual other spec, and should be fixed in abspos properly, by letting you override what you're positioning relative to.
571. # [11:38] <TabAtkins_> antonp: Bear in mind that we're not just talking about positioning, but also painting.
572. # [11:38] <TabAtkins_> antonp: If in the future we're going to let you throw your positioning root around, you're also changing positioning.
573. # [11:39] <TabAtkins_> s/changing positioning/changing painting/
574. # [11:39] <TabAtkins_> TabAtkins_: yeah, you're more or less moving it in the box tree.
575. # [11:39] <TabAtkins_> Bert: Another comparison is with shapes - if you can make two regions and flow between them, or put a shape on a single paragraph that duplicates the same size, why do those act differently?
576. # [11:39] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) (Ping timeout: 20 seconds)
577. # [11:40] <TabAtkins_> antonp: To be fair, you'll have different behavior anyway - the fragmentation is probably going to be different anyway.
578. # [11:40] <TabAtkins_> Rossen: Currently in shapes there's nothing taklinga bout this.
579. # [11:41] <TabAtkins_> Rossen: In the multishapes section, we're allowing multishapes.
580. # [11:41] <TabAtkins_> Rossen: Like if you extract a shape from an image, and it creates two circles.
581. # [11:41] <TabAtkins_> Rossen: The spec currently says its allowed, but doesn't define how it works.
582. # [11:42] <TabAtkins_> Rossen: Making a comparison based on that right now is a bit premature imo.
583. # [11:42] <TabAtkins_> Bert: maybe, but the examples I worked through often didn't matter - I could use multicol or regions, shapes or regions, they worked roughly equally well either way.
584. # [11:42] <TabAtkins_> Bert: So I thought that if they were so similar, they should perhaps all be the same.
585. # [11:42] <TabAtkins_> Bert: With their own possibilities, but the common elements should be the same.
586. # [11:43] <TabAtkins_> stearns: If we have stacking contexts, the only part that might be different is that content that overlaps at the boundaries might get painted over.
587. # [11:43] <TabAtkins_> stearns: That seems like a tiny edge-case for me. You generally avoid overlap.
588. # [11:43] * Joins: cox_ (~cox@public.irc.w3.org)
589. # [11:43] <TabAtkins_> Bert: I was thinking about abspos, actually.
590. # [11:43] <TabAtkins_> Bert: But I'm not sure how important it really is. I generally use abspos only as a last resort.
591. # [11:43] <TabAtkins_> stearns: It's certainly a limitation, and that's why I argued against it with my team.
592. # [11:44] <TabAtkins_> stearns: But finding use-cases where you want interleaved content...
593. # [11:44] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
594. # [11:44] * Joins: plh (plehegar@public.cloak)
595. # [11:44] * Joins: kotakagi2 (~kotakagi@public.cloak)
596. # [11:44] * Joins: liam (liam@public.cloak)
597. # [11:44] <TabAtkins_> stearns: From another direction, in all the use-cases we looked at, when you *have* interleaving, you always *want* a stacking context to prevent that from interleaving accidentally.
598. # [11:45] <TabAtkins_> TabAtkins_: So most interleaving is accidental and would benefit from stacking contexts, and the cases where it might be good are a corner-case, which might be best addressed in the future by a specialized property to group stacking contexts together.
599. # [11:45] <TabAtkins_> antonp: So are columns changing any?
600. # [11:45] <TabAtkins_> stearns: No.
601. # [11:46] <TabAtkins_> szilles: You'd need later to define that the stacking-context-grouping property auto-groups columns by default.
602. # [11:46] <TabAtkins_> arronei: Does it become a stacking context as soon as flow-from is set, even if it has no content?
603. # [11:46] <TabAtkins_> stearns: Yes, but then there's no content to be stacking-contexted.
604. # [11:46] * Joins: r12a (rishida@public.cloak)
605. # [11:47] <TabAtkins_> antonp: There was a comment from Hyatt about how content that flows through a region physically belong to the region.
606. # [11:47] <fantasai> r12a: http://wiki.csswg.org/topics/custom-ident-case-sensitivity
607. # [11:47] <TabAtkins_> antonp: Is this true, or does the content just flow through the space of the region?
608. # [11:47] * r12a tx fantasai
609. # [11:47] <TabAtkins_> stearns: I think that's relevant. If you're defining Regions to have stacking contexts, then it's the principle box of the Region that contains them, and the fragments of the flow are children of that in the box tree.
610. # [11:48] <TabAtkins_> antonp: Hyatt has said that would significantly complicate his implementation.
611. # [11:48] <TabAtkins_> stearns: He's gone back and forth on the issue. Not sure where he is on the issue right now.
612. # [11:48] <TabAtkins_> Rossen: I'm having a little trouble understanding what "physically belongs to" means.
613. # [11:48] <TabAtkins_> Rossen: Our model so far is that content flows through the region, and the regions are little viewports through which you view the content.
614. # [11:49] <TabAtkins_> Rossen: As you interact with the region, you change how much content is in each region.
615. # [11:49] <TabAtkins_> Rossen: But that doesn't mean actually changing the content in the document.
616. # [11:49] <TabAtkins_> Rossen: That complicates region styling.
617. # [11:49] <TabAtkins_> Rossen: Region styling has proven to be complicated for that reason.
618. # [11:50] * Joins: vhardy__ (~vhardy@public.cloak)
619. # [11:51] <TabAtkins_> TabAtkins_: Wrong level of discussion. Are the box-tree stuff from the flow children of the region's box? Or are they independent and just happen to be rendered with a geometric restriction that makes them look like the same?
620. # [11:51] <TabAtkins_> Rossen: The former (though it's complicated).
621. # [11:51] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
622. # [11:52] * Quits: kotakagi2 (~kotakagi@public.cloak) (Client closed connection)
623. # [11:52] <TabAtkins_> antonp: Makes sense - otherwise you get weird effects with things like a float "belonging" to another box entirely, which changes the rendering order.
624. # [11:52] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) (Ping timeout: 20 seconds)
625. # [11:52] <TabAtkins_> Bert: Is this similar to the relationship between lineboxes and inline content?
626. # [11:53] <TabAtkins_> TabAtkins_: Yes, very similar.
627. # [11:53] <TabAtkins_> stearns: Especially given the connection with styling ::first-line. Same exact problem as region styling.
628. # [11:54] <TabAtkins_> stearns: So back to the issue at hand - stacking contexts. Yay/nay?
629. # [11:55] <TabAtkins_> dbaron: I dont' have strong opinions. I don't think we ahve a strong performance reason to prefer full stacking context versus pseudo. But I'd have to ask roc about it.
630. # [11:55] <TabAtkins_> Rossen: I don't think performance is a strong reason to make a decision either way.
631. # [11:55] <TabAtkins_> TabAtkins_: yeah, not strong, but an input.
632. # [11:55] <TabAtkins_> Rossen: Right. I'm hearing, though, that some impls prefer it for performance reasons, and some don't care.
633. # [11:56] <TabAtkins_> RESOLVED: bug 15824 - keep the current spec text, where regions all create stackign contexts for the stuff flowed into them.
634. # [11:56] <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16858
635. # [11:56] <antonp> howcome: [something along the lines of I'm not sure whether pseudo-stacking contexts would be good enough, rather than full stacking contenxts]
636. # [11:56] <TabAtkins_> stearns: Should creation of regions from elements be disallowed?
637. # [11:57] <TabAtkins_> stearns: This came up about a year ago.
638. # [11:57] <TabAtkins_> stearns: I think there's a good reason to have this.
639. # [11:57] <TabAtkins_> stearns: It can inherit part of the structure of your document.
640. # [11:57] <TabAtkins_> stearns: Particularly for scripting/events.
641. # [11:57] * Joins: cabanier (~cabanier@public.cloak)
642. # [11:58] <TabAtkins_> stearns: I think we should have the ability to flow it into css-created boxes, but we shouldn't disallow it.
643. # [11:59] * Joins: virginie (~virginie@public.irc.w3.org)
644. # [11:59] <TabAtkins_> TabAtkins_: This is completely the issue I was taklign about yesterday, with changing over to dbaron's proposal.
645. # [12:00] * Joins: lstorset (~leif@public.cloak)
646. # [12:00] * Quits: lstorset (~leif@public.cloak) ("Leaving.")
647. # [12:00] * Joins: lstorset (~leif@public.cloak)
648. # [12:00] <TabAtkins_> stearns: Actually, you were doing an either-or. Either do dbaron's thing (no explicit region flow at all) or do Regions thing (explicit flow, with elements and such). So I'd like to resolve that, *if* we do that latter, we can use elements.
649. # [12:00] <TabAtkins_> TabAtkins_: I'm fine with that.
650. # [12:00] * Joins: kotakagi (~kotakagi@public.cloak)
651. # [12:01] <TabAtkins_> TabAtkins_: I'm not happy about being forced to use dummy elements, but it's better in my book than the alternatives, given the lack of dedicated pseudo-element creation right now.
652. # [12:01] <TabAtkins_> stearns: There's an example by implication in note 3 about how you don't necessarily have to use dummy elements.
653. # [12:02] <dbaron> howcome: ...
654. # [12:02] <divya> TabAtkins: we dont need to handle eventing on pseudo-elements
655. # [12:03] <divya> TabAtkins: if we end up going with current regions proposal there are a lot of things that wont work well and wont work accessibly if we just stick to pseudo elements
656. # [12:03] <stearns> http://wiki.csswg.org/spec/css3-regions/regions-use-cases#converting-hard-breaks-to-named-flows
657. # [12:03] <divya> TabAtkins: if we go with dbaron's proposal we will still have …
658. # [12:03] <divya> howcome: if we need the DOM thing, then put up a proposal for that.
659. # [12:03] <divya> glazou: you raised a problem then why dont you do it?
660. # [12:03] * Quits: vhardy__ (~vhardy@public.cloak) (vhardy__)
661. # [12:03] <divya> howcome: I dont have dom issue.
662. # [12:03] <divya> glazou: this is lower in priority.
663. # [12:04] <divya> glazou: i am just saying people like regions given …
664. # [12:04] <divya> howcome: I am never going to agree to a solution based on dummy html elements you are not going to get my okay for that.
665. # [12:04] <divya> TabAtkins: i use dummy html as wrappers all the time, it is going to be necessary sometimes
666. # [12:04] <divya> howcome: you are creating a separate structure next to content structure
667. # [12:05] <divya> stearns: that visual structure in a lot of interesting pieces has to have a structure, you have to have nesting in child-parent rels
668. # [12:05] <dbaron> (Tab also said something unminuted after the "howcome: ...")
669. # [12:05] <divya> stearns: one of the args against … is that you are reinventing html in css
670. # [12:05] <divya> glazou: when you do TOCs and extract them, you do want elements.
671. # [12:05] * Quits: cox_ (~cox@public.irc.w3.org) (Ping timeout: 20 seconds)
672. # [12:05] * fantasai suggests adopting XSLT as a solution this ;)
673. # [12:05] <divya> stearns: it is quite similar to what is being done in SHADOW DOM
674. # [12:06] <Bert> (HTML could add a <toc> element.)
675. # [12:06] <divya> stearns: you have an insertion point that is an empty element in your shadow dom tree. that seems to be something people want as well. we are providing a similar facility.
676. # [12:06] * liam \o/ XSLT
677. # [12:06] <divya> TabAtkins: the point of shadow dom is recognizing that you need dummy elements and taking them from the main flow.
678. # [12:07] <divya> stearns: in MS you have two separate html documents you have content and vi…
679. # [12:07] <divya> howcome: i dont think you can make the argument that they are semantic
680. # [12:07] <divya> howcome: we need representation of visual structure, we should not abuse html documents for that.
681. # [12:08] <divya> stevezilles: i am sorry visual structure is semantic
682. # [12:08] <divya> TabAtkins: philosophically opposed but not practically opposed
683. # [12:08] <Bert> q+ to say using an external (XML) document for the visual structure is a different case again, and OK
684. # [12:08] * Zakim sees Bert on the speaker queue
685. # [12:08] <divya> howcome: building on what you said, if we agree on going david's way we should do that.
686. # [12:08] <divya> TabAtkins: within option b lets not screw around and allow that, as it is required for regions proposal to work well.
687. # [12:09] <divya> howcome: it is not well defined if it requires html
688. # [12:09] <divya> [lots of arguments]
689. # [12:10] <divya> glazou: authors already use elements for layouts.
690. # [12:10] <divya> glazou: they will continue to do it
691. # [12:10] <divya> TabAtkins: my arg is what stearns suggests is improv over what we have right now.
692. # [12:10] <divya> TabAtkins: you would have to explicitly break contents between the elements right now.
693. # [12:10] <divya> TabAtkins: you have same divs sitting around, but you get better semantics with the content and more reliable styling.
694. # [12:11] <divya> howcome: as soon as you change the font size.
695. # [12:11] <divya> dbaron: assuming people will do things in the same proportion to they do things right now.
696. # [12:11] <fantasai> dbaron: The strictly better than right now is assuming that people will do things in the same proportion to te rate they do them right now
697. # [12:11] <fantasai> dbaron: But this will change the rate at which people do such things.
698. # [12:11] * divya fantasai would you like to take over
699. # [12:12] * fantasai not really :)
700. # [12:12] * divya has lost a few seconds
701. # [12:12] * fantasai but could if you want
702. # [12:12] * fantasai doesn't think anything was lost, it's in the minutes from February
703. # [12:12] <fantasai> ;P
704. # [12:12] * divya hahahhaa
705. # [12:12] <divya> TabAtkins: if we are selecting columns you are using pseudo elements
706. # [12:12] * Joins: Jirka (~jirka@public.cloak)
707. # [12:13] <divya> TabAtkins: there is no reason to cripple the alternative right now.
708. # [12:13] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
709. # [12:13] <divya> TabAtkins: if we dont need it then stop caring about it.
710. # [12:13] <divya> glazou: all specs rely on implementation in the long run, if we dont have 2 impl. then it would go away.
711. # [12:14] <divya> steve zilles: people being forced to divide content to make it look like what it looks like.
712. # [12:14] <divya> steve zilles: you have restructured it in a form that defeats accessible access
713. # [12:15] <divya> steve zilles: you want to show content for different devices and you cant do it.
714. # [12:15] <glazou> Zakim, q+
715. # [12:15] <Zakim> I see Bert, glazou on the speaker queue
716. # [12:15] * Quits: rubylin (~rubylin@public.cloak) (Ping timeout: 20 seconds)
717. # [12:15] <divya> steve zilles: html as a suitable lang to express viz structure, it is possible to explore restricting the use of regions to page templates and in that context require they be empty boxes
718. # [12:15] <TabAtkins_> howcome: I think the page template proposal is much more sensible in that regard.
719. # [12:16] <TabAtkins_> szilles: In that case regions would end up with addressable things - we'd get CSSOM access to them.
720. # [12:16] <TabAtkins_> stearns: The OM stuff is in a separate spec entirely - the pseudo spec Daniel and I are doing.
721. # [12:16] * Joins: rubylin (~rubylin@public.cloak)
722. # [12:17] <TabAtkins_> szilles: The main reason for this is exactly what Tab said - from a practical viewpoint, elements work today, and they're eventable/scriptable/etc. This needs to be there for a lot of use-cases.
723. # [12:17] <TabAtkins_> szilles: If you're paginating a complex structure, you don't know what the use-cases are today, and we won't know what they are until we see them in the wild.
724. # [12:17] <TabAtkins_> szilles: You can come up with a few simple rules, but they dont' generalize right now.
725. # [12:17] <Bert> zakim, ack me
726. # [12:17] <Zakim> Bert, you wanted to compare regions with columns and to say using an external (XML) document for the visual structure is a different case again, and OK
727. # [12:17] <TabAtkins_> Bert: Two remakrs.
728. # [12:17] <Zakim> I see glazou on the speaker queue
729. # [12:18] * Quits: plh (plehegar@public.cloak) ("always accept cookies")
730. # [12:18] <TabAtkins_> Bert: I've been watiing for regions for 15+ years.
731. # [12:18] <TabAtkins_> Bert: If we're waiting for events to be defined on them, cool, let's do that. If it takes a year, okay.
732. # [12:18] * leaverou Apologies, I have to leave a bit early
733. # [12:18] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
734. # [12:19] <TabAtkins_> Bert: going back to an example from alan was using an external document to define the regions. This seems fine to me as well, as long as those extra element are clearly marked as being in a document which is defined as being for layout, not meaning.
735. # [12:19] * leaverou is now known as leaverou_away
736. # [12:19] <TabAtkins_> stearns: Certainly something MS has been working on - content in one doc and visual structure in the other - and we've been doing experiments with Shadow DOM, with similar effects.
737. # [12:19] <glazou> Zakim, ack me
738. # [12:19] <Zakim> I see no one on the speaker queue
739. # [12:20] <TabAtkins_> stearns: Either way, they're separated from the meaningful HTML.
740. # [12:20] * sylvaing "CSS Regions: they work in practice but fail in theory"
741. # [12:20] <TabAtkins_> glazou: I was speaking at the Paris Web Conf last week.
742. # [12:20] <TabAtkins_> glazou: I demoed Regions and other things, and people came to the end of my talk.
743. # [12:20] <dbaron> q+
744. # [12:20] * Zakim sees dbaron on the speaker queue
745. # [12:21] <TabAtkins_> glazou: they said pseudos were bad because screen-readers dont' read pseudos.
746. # [12:21] * Quits: rubylin (~rubylin@public.cloak) ("")
747. # [12:21] <TabAtkins_> TabAtkins_: I think they misunderstand. The real content will still be in the DOM, in a single element.
748. # [12:22] <dbaron> q-
749. # [12:22] * Zakim sees no one on the speaker queue
750. # [12:22] <TabAtkins_> stearns: By the time you get to the reader, you're not looking quite at the DOM.
751. # [12:22] <TabAtkins_> TabAtkins_: Not quite - they vary. You usually get an accessibility tree, which is an expanded version of the DOM.
752. # [12:22] * hober picked the best seat
753. # [12:22] <TabAtkins_> howcome: If pseudos dont' work, then why don't multicol work? They're pseudos too.
754. # [12:23] <TabAtkins_> dbaron: There's a long-standing problem with people trying to put *content* into the pseudos, rather than in the document.
755. # [12:23] * Joins: shepazu (schepers@public.cloak)
756. # [12:23] * Quits: tomoyuki (~tshimizu3@public.cloak) (Client closed connection)
757. # [12:23] <dbaron> dbaron: ... ...
758. # [12:23] <dbaron> TabAtkins: If that's a problem then we also need to throw away flexbox and grid for the same reason.
759. # [12:24] <dbaron> TabAtkins: If people have learned that putting content in pseduos in bad, they'll interpret what you say as the same bad thing.
760. # [12:24] <dbaron> TabAtkins: I think their concern is actually mistaken.
761. # [12:24] <antonp> +!
762. # [12:24] * Zakim wonders where ! is
763. # [12:24] <antonp> +1
764. # [12:24] <dbaron> glazou: Let's take a flow that ...
765. # [12:24] <dbaron> glazou: The voice reador should say "moving from one column to ..."
766. # [12:24] <dbaron> ?: why?
767. # [12:24] * Quits: mjs (~mjs@public.cloak) (mjs)
768. # [12:25] <dbaron> TabAtkins: Regions encourages you to have a semantically whole pice of your content even if it's split visually.
769. # [12:25] * leaverou_away is now known as leaverou
770. # [12:25] * Quits: evanli (~androirc@public.cloak) (Ping timeout: 20 seconds)
771. # [12:25] <dbaron> TabAtkins: Accessibility could be better in general when display order is different from source order.
772. # [12:25] <dbaron> glazou: I was just reporting what I heard
773. # [12:25] <TabAtkins_> stearns: Unless anyone has something to continue in this discussion, I'd like to close it. Leave the issue in the spec and continue on.
774. # [12:25] <TabAtkins_> stearns: The next thing is quick.
775. # [12:25] <TabAtkins_> stearns: I think it was resolved yesterday.
776. # [12:26] <TabAtkins_> stearns: How the regions specification defines the first region box as the ICB of the named flow.
777. # [12:26] <TabAtkins_> stearns: I wasn't sure if that was exactly necessary, but in the discussion yesterday about paged media and the talk about first page and ICB and such...
778. # [12:27] <TabAtkins_> stearns: I think regions just needs to follow what is going on in pages.
779. # [12:27] <TabAtkins_> TabAtkins_: I think arronei thought up a name for the concept you need: "fragmentation containing block". For the concept syou need to pull from the ICB, without the *full* assortment of baggage from it.
780. # [12:28] <fantasai> fragmentaining block!
781. # [12:28] * sylvaing fragmentaining block party!
782. # [12:29] * divya now occurring @ Saint Clair 3A
783. # [12:29] <TabAtkins_> TabAtkins_: So we need to define exactly what parts of the current ICB concept need to be pulled out into FCB, because non-initial pages/regions/etc need them. Then write that down and reference it in Page and Regions.
784. # [12:29] * dbaron hopefully not like the sort that happened near where I live in SF a few hours ago
785. # [12:29] * Bert : As long as "leaving the issue in the spec" doesn't mean: "we'll ask at every meeting until thee's meeting with so few people that we can officially decide to do it anyway."
786. # [12:30] <TabAtkins_> RESOLVED: What Tab said immediately above about ICB/FCB
787. # [12:31] * Quits: Norbert_ (~Norbert@public.irc.w3.org) (Ping timeout: 20 seconds)
788. # [12:31] <dbaron> Topic: Multicol
789. # [12:31] <TabAtkins_> Topic: multicol sizing
790. # [12:32] <dbaron> http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm
791. # [12:32] <TabAtkins_> fantasai: The proposal is to replace the "available width" and "shrink-to-fit" variables with just "used width".
792. # [12:32] * Quits: lmclister (~lmclister@public.irc.w3.org) (Ping timeout: 20 seconds)
793. # [12:32] <TabAtkins_> fantasai: And remove lines 3-10 of the pseudo-algo and just swap out refs for "used width".
794. # [12:32] <TabAtkins_> fantasai: Where used width is defined by referenced formulas.
795. # [12:33] <TabAtkins_> howcome: We presume when used width is handled, so we're shuffling where things are done.
796. # [12:33] * Quits: rhauck (~rhauck@public.irc.w3.org) (Ping timeout: 20 seconds)
797. # [12:33] <TabAtkins_> howcome: So it's a simplification of multicol, and it doesn't make a compliant impl non-compliant, so I don't have a problem with it.
798. # [12:33] <TabAtkins_> howcome: [something about min and max width]
799. # [12:34] <TabAtkins_> fantasai: That's contained in "used width". It's the result of all the computations about what the width is going to be.
800. # [12:34] <TabAtkins_> howcome: It seems you've been wanting to have a discussion about min-width in this spec, but maybe I'm wrong.
801. # [12:34] * Joins: kawabata (~kawabata@public.cloak)
802. # [12:34] <TabAtkins_> SimonSapin: When is the available width unknown?
803. # [12:34] <TabAtkins_> SimonSapin: The spec has one example - in floats.
804. # [12:34] <TabAtkins_> SimonSapin: but that's no longer unknown, and it's defined in Sizing.
805. # [12:35] <TabAtkins_> howcome: So no other changes, just these removals/swaps? No additional complexities?
806. # [12:35] * hober gnaws own arm off.
807. # [12:35] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
808. # [12:35] <TabAtkins_> Bert: I'm not completely clear on what the change is.
809. # [12:35] <TabAtkins_> fantasai: The available width is always known.
810. # [12:35] <TabAtkins_> dbaron: You're removing the stuff about shrink-to-fit into Sizing, so for the purposeof this spec, available width is always known.
811. # [12:36] * Quits: kotakagi (~kotakagi@public.cloak) (Ping timeout: 20 seconds)
812. # [12:36] <dbaron> fantasai, ...: yes
813. # [12:36] <TabAtkins_> fantasai: Right, becasue this spec isn't defining things well enough, and we shouldn't be dealing with this stuff in this CR right now.
814. # [12:36] <TabAtkins_> SimonSapin: In 2.1, what we call available width is based on containing block, but in here it's not the same.
815. # [12:36] <TabAtkins_> howcome: Right, that's confusing.
816. # [12:37] <TabAtkins_> Rossen: Another is the "used width", which in 2.1 terms is the final width, can still change here afterwards.
817. # [12:37] <TabAtkins_> Rossen: If you came in with width:auto and have a column-count, it can still change here.
818. # [12:37] <TabAtkins_> Rossen: So you're either oging to have a complete used-width spec somewhere else, and thus yank out these two usages.
819. # [12:37] <TabAtkins_> Rossen: or redefine shrink-to-fit elsewhere and don't call it used width here.
820. # [12:38] <TabAtkins_> fantasai: The sizing spec defines the used width (in conjunction with 2.1).
821. # [12:38] <TabAtkins_> fantasai: The purpose of this algo is not to figure out the width of the element, but to figure out how many columns and how wide they are.
822. # [12:38] <TabAtkins_> fantasai: So we can assume that we've already figured out the width.
823. # [12:38] <TabAtkins_> Bert: but you need that information to figure out the width.
824. # [12:39] <TabAtkins_> TabAtkins: Right, you do use that in Sizing to figure out the width.
825. # [12:39] <TabAtkins_> Bert: So all that happens *before* you figure out the intrinsic size.
826. # [12:39] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
827. # [12:39] <TabAtkins_> fantasai: It's more complicated. [summarizes the shrink-to-fit algo in Sizing]
828. # [12:40] <TabAtkins_> fantasai: So this formula in multicol is technically wrong - it overflows when unnecessary in some cases.
829. # [12:40] * Quits: yaso (~yaso@public.cloak) (yaso)
830. # [12:40] <TabAtkins_> howcome: It's not *wrong*, but it might not be what you want.
831. # [12:41] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
832. # [12:41] * Quits: r12a (rishida@public.cloak)
833. # [12:41] <fantasai> http://dev.w3.org/csswg/css3-sizing/
834. # [12:41] <TabAtkins_> TabAtkins: Lines 5-8 aren't great. Sizing defines a slightly better definition that doesn't overflow as often.
835. # [12:42] <TabAtkins_> fantasai: Because this definition is a bit complicated, I don't think this CR (multicol) is the right place to deal with this.
836. # [12:43] * Joins: florianr (~yaaic@public.cloak)
837. # [12:43] <TabAtkins_> glazou: We brought this up weeks ago, and deferred it to the f2f to resolve on it.
838. # [12:43] <SimonSapin> q+
839. # [12:43] * Zakim sees SimonSapin on the speaker queue
840. # [12:43] <TabAtkins_> howcome: I agree we should kill lines 9-10.
841. # [12:43] * Joins: oyvind (~oyvinds@public.cloak)
842. # [12:43] <TabAtkins_> howcome: I don't think we need to remove lines 3-4, seems like useful information.
843. # [12:44] <TabAtkins_> howcome: 5-8 gives *a* definition, even if it's not ideal.
844. # [12:44] <TabAtkins_> TabAtkins: We should kill it if we know we have a better definition, which we do in Sizing.
845. # [12:44] <TabAtkins_> dbaron: The definition in 19-23 is more complicated - you dont' want to get a different result from 5-8 as from 19-23, once you get a definite width.
846. # [12:45] <fantasai> The point is, that this pseudo-algorithm should restrict itself to determining the number and width of the columns, because the rules for sizing a multi-col are not clear, not interoperable, and not agreed-upon
847. # [12:45] <TabAtkins_> Bert: But that's in a float situation. I asked for column counta nd width, shouldn't i get it?
848. # [12:46] <TabAtkins_> TabAtkins: Floats dont' overflow their containing block unless absolutely necessary. Our better definition tweaks things if necessary to maintain that invariant.
849. # [12:46] <TabAtkins_> SimonSapin: Importantly, what does "unknown width" actually mean?
850. # [12:47] <TabAtkins_> dbaron: You could interpret it as two different things, one is "you are currently doing preferred / minimum intrinsic width calculation", the other is "that, plus you have a shrink-to-fit width or any sort".
851. # [12:47] <TabAtkins_> dbaron: I think Simon's proposal is takign the first.
852. # [12:47] <dbaron> I think
853. # [12:47] <TabAtkins_> glazou: It seems that some work has to be done on this in any way, because some definitions are missing or unclear.
854. # [12:48] * Quits: virginie (~virginie@public.irc.w3.org) (Ping timeout: 20 seconds)
855. # [12:48] <TabAtkins_> fantasai: Yes. So we should not be leaving these in the spec. We should pull them out and let Sizing define it.
856. # [12:49] <dbaron> dbaron: I think we should take the proposal, and raise further issues as they come up.
857. # [12:49] <TabAtkins_> glazou: Straw poll, 6 for, 1 against, many abstain/undecided
858. # [12:49] <TabAtkins_> glazou: Those who are undecided, can you trust the group?
859. # [12:50] <fantasai> The proposal is, remove lines 3-10 in the pseudo-algorithm, use the term "used-width' rather than "available-width", and define in css3-multicol that "used-width" is undefined; work on it in css3-sizing
860. # [12:50] <TabAtkins_> Rossen: There seems to be some conflicting terminology. It seems to be complicated.
861. # [12:50] <TabAtkins_> Rossen: I'm interested in resolving this in favor of Sizing. I just want to minimize damage on this spec.
862. # [12:52] <TabAtkins_> glazou: Okay, so discuss before tomorrow evening, and we will resolve. Otherwise, deferred.
863. # [12:52] * Quits: glazou (~glazou@public.cloak) (glazou)
864. # [12:52] * Quits: divya (~Adium@public.cloak) ("Leaving.")
865. # [12:52] <dbaron> lunch break until 2pm
866. # [12:52] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
867. # [12:52] * Quits: stearns (~anonymous@public.cloak) (stearns)
868. # [12:52] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
869. # [12:52] * Quits: dino (~dino@public.cloak) (dino)
870. # [12:52] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 20 seconds)
871. # [12:53] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 20 seconds)
872. # [12:53] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 20 seconds)
873. # [12:53] * Joins: kensaku (~kensaku@public.cloak)
874. # [12:53] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 20 seconds)
875. # [12:53] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 20 seconds)
876. # [12:54] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 20 seconds)
877. # [12:54] * Quits: sakkuru (~sakih@public.cloak) (Ping timeout: 20 seconds)
878. # [12:54] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 20 seconds)
879. # [12:54] * Quits: krit (~krit@public.cloak) ("Leaving.")
880. # [12:54] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
881. # [12:54] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 20 seconds)
882. # [12:54] * Quits: jet (~jet@public.cloak) (jet)
883. # [12:56] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
884. # [12:58] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 20 seconds)
885. # [12:59] * Joins: tomoyuki (~tshimizu3@public.cloak)
886. # [12:59] * sylvaing is now known as sylvaing_away
887. # [13:00] * Quits: Jirka (~jirka@public.cloak) (Jirka)
888. # [13:02] * Disconnected
889. # [13:03] * Attempting to rejoin channel #css
890. # [13:03] * Rejoined channel #css
891. # [13:03] * Topic is '#css We tjoml we [refer s;ogjt;u tje pver;fpw regopms a[[rpacj tp tje exact sumtax tjat regopms os isomg rogjt mpw. becaise ot'
892. # [13:03] * Set by glazou on Sun Oct 28 17:26:36
893. # [13:04] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
894. # [13:04] * Quits: florianr (~yaaic@public.cloak) ("")
895. # [13:06] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
896. # [13:11] * Joins: boblet (~uid1921@public.cloak)
897. # [13:14] * leaverou is now known as leaverou_away
898. # [13:16] * Joins: stearns (~anonymous@public.cloak)
899. # [13:25] * Quits: stearns (~anonymous@public.cloak) (Ping timeout: 20 seconds)
900. # [13:35] * Joins: rotsuya (~rotsuya@public.cloak)
901. # [13:36] * Joins: franremy (~franremy@public.cloak)
902. # [13:38] * Joins: SimonSapin (~simon@public.cloak)
903. # [13:38] * Quits: tomoyuki (~tshimizu3@public.cloak) (Ping timeout: 20 seconds)
904. # [13:39] * Joins: rotsuya_ (~rotsuya@public.cloak)
905. # [13:39] * Joins: tomoyuki (~tshimizu3@public.cloak)
906. # [13:39] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
907. # [13:40] * Joins: SimonSapin (~simon@public.cloak)
908. # [13:41] * Quits: rotsuya (~rotsuya@public.cloak) (Ping timeout: 20 seconds)
909. # [13:41] * Joins: mjs (~mjs@public.cloak)
910. # [13:43] * Joins: rotsuya (~rotsuya@public.cloak)
911. # [13:44] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
912. # [13:45] * Quits: rotsuya_ (~rotsuya@public.cloak) (Ping timeout: 20 seconds)
913. # [13:46] * Joins: shepazu (schepers@public.cloak)
914. # [13:46] * sylvaing_away is now known as sylvaing
915. # [13:50] * Joins: r12a (rishida@public.cloak)
916. # [13:51] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 20 seconds)
917. # [13:54] * Joins: arronei (~arronei@public.cloak)
918. # [13:54] * Joins: kensaku (~kensaku@public.cloak)
919. # [13:56] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 20 seconds)
920. # [13:58] * Joins: arronei (~arronei@public.cloak)
921. # [14:02] * Joins: franremy (~franremy@public.cloak)
922. # [14:04] * Joins: sakkuru (~sakih@public.cloak)
923. # [14:06] * Joins: glenn (~gadams@public.cloak)
924. # [14:06] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 20 seconds)
925. # [14:06] * Quits: sakkuru (~sakih@public.cloak) (Ping timeout: 20 seconds)
926. # [14:07] * Joins: sakkuru (~sakih@public.cloak)
927. # [14:07] * Joins: cabanier (~cabanier@public.cloak)
928. # [14:08] * Joins: yaso (~yaso@public.cloak)
929. # [14:09] * Joins: krit (~krit@public.cloak)
930. # [14:09] * Quits: mjs (~mjs@public.cloak) (mjs)
931. # [14:10] * Joins: Jirka (~jirka@public.cloak)
932. # [14:10] * Joins: antonp (~Thunderbird@public.cloak)
933. # [14:10] * Joins: mjs (~mjs@public.cloak)
934. # [14:11] * Joins: dbaron (~dbaron@public.cloak)
935. # [14:11] * Joins: glazou (~glazou@public.cloak)
936. # [14:12] * Joins: mgylling (~mgylling@public.cloak)
937. # [14:15] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
938. # [14:15] * Joins: franremy (~franremy@public.cloak)
939. # [14:16] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
940. # [14:16] * Joins: dino (~dino@public.cloak)
941. # [14:16] * Joins: cabanier (~cabanier@public.cloak)
942. # [14:17] * Joins: florianr (~yaaic@public.cloak)
943. # [14:17] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
944. # [14:20] * Joins: divya (~Adium@public.cloak)
945. # [14:20] * Quits: divya (~Adium@public.cloak) (Client closed connection)
946. # [14:20] * Joins: divya1 (~Adium@public.cloak)
947. # [14:20] * Quits: r12a (rishida@public.cloak) (Client closed connection)
948. # [14:21] * Joins: r12a (rishida@public.cloak)
949. # [14:21] * leaverou_away is now known as leaverou
950. # [14:21] * Joins: slightlyoff (~u1768@public.cloak)
951. # [14:21] * Joins: cabanier (~cabanier@public.cloak)
952. # [14:22] <TabAtkins_> Topic: CSS Animations
953. # [14:22] * divya1 is now known as divya
954. # [14:22] * Joins: cox (~cox@public.irc.w3.org)
955. # [14:22] * Joins: yamaday (~yamaday@public.cloak)
956. # [14:22] * Joins: lstorset (~leif@public.cloak)
957. # [14:22] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
958. # [14:22] * Joins: antonp (~Thunderbird@public.cloak)
959. # [14:22] * Joins: Rossen (~Rossen@public.cloak)
960. # [14:22] * Joins: chsiao (~chatzilla@public.cloak)
961. # [14:22] * Joins: liam (liam@public.cloak)
962. # [14:23] <JohnJansen> rumor has it that a photo was just taken...
963. # [14:23] <TabAtkins_> Rumor has it that we did it quick before you found out...
964. # [14:23] <JohnJansen> as long as sylvain was in it, that's cool.
965. # [14:24] <TabAtkins_> Topic: CSS Masking
966. # [14:24] <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
967. # [14:24] * Joins: kawabata (~kawabata@public.cloak)
968. # [14:24] <TabAtkins_> krit: This spec aims to combine Masking in FF and Webkit, combine to a common spec. Takes from SVG Masking and Clipping, and specifies how WebKit works.
969. # [14:24] <TabAtkins_> krit: Have a few issues left.
970. # [14:24] <TabAtkins_> krit: First is mask-clip.
971. # [14:25] <TabAtkins_> krit: CSs Masking in webkit is pretty similar to background and its properties.
972. # [14:25] * Joins: Norbert (~Norbert@public.irc.w3.org)
973. # [14:25] <TabAtkins_> krit: While a background is always limited to the border box ( you can't draw otuside of it), CSS masking might want to go outside of this box.
974. # [14:25] <TabAtkins_> krit: For example, a child element overflowing the main element, people may want to have a mask that covers the whole thing and doesn't auto-clip away the overflow.
975. # [14:26] <TabAtkins_> krit: But right now mask-clip only has the same property as background-clip.
976. # [14:26] <TabAtkins_> krit: I'd like another keyword that takes into account the boxes of children.
977. # [14:26] * Quits: shepazu (schepers@public.cloak)
978. # [14:26] * Joins: shepazu (schepers@public.cloak)
979. # [14:26] <TabAtkins_> TabAtkins_: So, not things like shadows? Just the union of geometry, like getboundingClientRect?
980. # [14:26] <TabAtkins_> krit: Yes.
981. # [14:27] <TabAtkins_> krit: Another issue - SVG percentages in a clip need to resolve against a box. I'd like to let this "union box" also be usable for resolving percentages against.
982. # [14:27] <TabAtkins_> krit: Another related issue - set the clip area to the same as the filtered area.
983. # [14:27] * Joins: Reinaldo_ (~Reinaldo@public.irc.w3.org)
984. # [14:27] <TabAtkins_> krit: For example, be able to put a clip on a blurred element without necessarily auto-clipping the part of blur that goes outside the geometry.
985. # [14:28] * Quits: trackbot (trackbot@public.irc.w3.org) (Client closed connection)
986. # [14:28] <TabAtkins_> krit: roc suggested a "none" value, with no automatic limitations (or UA-defined ones based on knowledge of painting). However, we still need to decide what SVG percentages are resolved against.
987. # [14:28] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) (Ping timeout: 20 seconds)
988. # [14:29] <TabAtkins_> krit: We could use the "union box" for that too - difference being that stuff outside the 0%-100% range are actually still useful.
989. # [14:29] * Joins: trackbot (trackbot@public.cloak)
990. # [14:29] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
991. # [14:30] <TabAtkins_> dbaron: That's a little weird, if the blur is part of the bounding box.
992. # [14:31] <TabAtkins_> TabAtkins_: It's not - it's just whatever bounding client rect would return.
993. # [14:32] <TabAtkins_> krit: Next question, origin of the coord space. Since you're referencing an SVG image, how do you position the image? x/y attributes on the root <svg> element? Is that allowed?
994. # [14:32] <TabAtkins_> TabAtkins_: It's allowed, but I think it's meaningless right now. We could maybe fix that.
995. # [14:33] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
996. # [14:33] <TabAtkins_> krit: And for PNG it would just sit at the 0,0 of the coord space?
997. # [14:33] * Joins: yamaday (~yamaday@public.cloak)
998. # [14:33] <TabAtkins_> TabAtkins_: Yes.
999. # [14:33] <TabAtkins_> krit: Ok, but then you still can't ever mask a blur with a PNG - the blur part will always be outside of whatever boxes you use for the coord space.
1000. # [14:34] <TabAtkins_> TabAtkins_: Okay, so we might want a clip-margin then, to allow the author to manually expand the clipping box further.
1001. # [14:34] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
1002. # [14:34] * Joins: trackbot (trackbot@public.cloak)
1003. # [14:34] <TabAtkins_> krit: Ok, if you're willing to help me figure that out, we can leave it unresolved for now.
1004. # [14:34] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
1005. # [14:35] * Joins: tomoyuki (~tshimizu3@public.cloak)
1006. # [14:35] <TabAtkins_> TabAtkins_: Okay, so two additions to the spec being reviewed right now:
1007. # [14:36] <TabAtkins_> TabAtkins_: 1) Add a new value to mask-clip/origin which uses the "bounding box" - same as returned by getBoundingClientRect.
1008. # [14:36] <TabAtkins_> TabAtkins_: 2) Add a new "none" value which has no auto-clipping, and which sets the origin/extent of coordinate sapce same as "bounding box" value.
1009. # [14:37] <TabAtkins_> plinss: So the initial suggestion was just to add a "none" keyword?
1010. # [14:37] <TabAtkins_> RESOLVED: Add the two new values to mask-clip/origin as described above.
1011. # [14:37] * Quits: yaso (~yaso@public.cloak) (yaso)
1012. # [14:38] * Joins: jfmoy (~jfmoy@public.cloak)
1013. # [14:38] * Parts: jfmoy (~jfmoy@public.cloak) (jfmoy)
1014. # [14:38] * Joins: trackbot (trackbot@public.cloak)
1015. # [14:38] <TabAtkins_> TabAtkins_: Has anyone asked for the "bounding rect" clip?
1016. # [14:38] * Joins: stearns (~anonymous@public.cloak)
1017. # [14:38] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
1018. # [14:39] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
1019. # [14:39] <TabAtkins_> krit: Firefox does the "none" value right now.
1020. # [14:39] <TabAtkins_> TabAtkins_: Okay, so maybe just do the "none" value now, and reserve the explicit "bounding rect" clip for later.
1021. # [14:39] <TabAtkins_> RESOLVED: Amend previous resolution - only agree to add the "none" value.
1022. # [14:39] <TabAtkins_> Bert: Do we need to coordinate with SVG on this?
1023. # [14:40] <TabAtkins_> krit: SVG already decided on it - this is SVG coming to CSS to sanity-check/bless it.
1024. # [14:40] <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#ClipProperty
1025. # [14:40] <TabAtkins_> krit: The 'clip' property only applies to abspos elements, using the rect() function.
1026. # [14:41] <TabAtkins_> krit: But clip-path() works on everything, with more shape functions and an SVG <clipPath> element reference.
1027. # [14:41] <TabAtkins_> s/clip-path()/'clip-path'/
1028. # [14:41] <TabAtkins_> TabAtkins_: So do we want to unify the two properties?
1029. # [14:41] * Joins: yaso (~yaso@public.cloak)
1030. # [14:43] <TabAtkins_> krit: I think I don't - people might be confused about using both rect() and another shape (doing one on :hover, for instance) and not knowing why one doesn't work (since rect() would, for legacy reasons, only work on abspos elements).
1031. # [14:43] <TabAtkins_> TabAtkins_: Okay, so you're suggesting deprecating 'clip' and using only 'clip-path'.
1032. # [14:45] * Zakim excuses himself; his presence no longer seems to be needed
1033. # [14:45] * Parts: Zakim (zakim@public.irc.w3.org) (Zakim)
1034. # [14:45] <TabAtkins_> plinss: Sorta sad - clip was the first one that we ever did with the intention of being extended with more functions like this.
1035. # [14:47] * glazou loves how zakim quites the channel first and apologizes for that later
1036. # [14:47] <glazou> s/quites/quits
1037. # [14:48] * Joins: Zakim (zakim@public.irc.w3.org)
1038. # [14:48] * dbaron Zakim, remind us in 191 minutes to go home
1039. # [14:48] * Zakim ok, dbaron
1040. # [14:48] <TabAtkins_> RESOLVED: Deprecate 'clip', recommend 'clip-path' from now on.
1041. # [14:49] <TabAtkins_> TabAtkins_: Related to this, can we add an inset-rectangle()?
1042. # [14:50] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
1043. # [14:50] <TabAtkins_> dbaron: We have a standing resolution from 2001 to add an inset-rect()
1044. # [14:50] <dbaron> Redwood City in 2001
1045. # [14:50] * Joins: yamaday (~yamaday@public.cloak)
1046. # [14:50] <dbaron> (which was only the second WG meeting I attended in person)
1047. # [14:51] <TabAtkins_> everyone: sounds good, make Rossen do it.
1048. # [14:51] <TabAtkins_> ACTION rossen to add inset-rectangle(top, right, bottom, left) to the Shapes spec.
1049. # [14:52] * fantasai suggests just calling it 'inset()'
1050. # [14:52] * Joins: trackbot (trackbot@public.cloak)
1051. # [14:52] <TabAtkins_> ACTION rossen to add inset-rectangle(top, right, bottom, left) to the Shapes spec. (or just inset()).
1052. # [14:52] * trackbot noticed an ACTION. Trying to create it.
1053. # [14:52] <trackbot> Created ACTION-514 - Add inset-rectangle(top, right, bottom, left) to the Shapes spec. (or just inset()). [on Rossen Atanassov - due 2012-11-05].
1054. # [14:52] <TabAtkins_> RESOLVED: Add inset() or inset-rectangle() to the Shapes module.
1055. # [14:52] <TabAtkins_> krit: Last issue is the 'mask' shorthand.
1056. # [14:53] <TabAtkins_> krit: 'maks' property in SVG takes a ref to a <mask> element.
1057. # [14:53] <TabAtkins_> krit: Webkit takes just CSS images.
1058. # [14:53] <TabAtkins_> krit: roc complained that these are not fully compatible with each other
1059. # [14:54] <TabAtkins_> krit: it's not fully clear when pointing to an SVG document whether to use it as an "image" or as an "image source" (a CSS image, in other words).
1060. # [14:54] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
1061. # [14:54] * Joins: yamaday (~yamaday@public.cloak)
1062. # [14:54] <krit> TabAtkins: If you have a URL fucntion with an hash, it is not clear if you refer an SVG element or an paint server, or an resource
1063. # [14:54] * Quits: mjs (~mjs@public.cloak) (mjs)
1064. # [14:55] <krit> TabAtkins: CSS would like to integrate into SVG further
1065. # [14:55] <krit> TabAtkins: fill and stroke would take CSS IMages
1066. # [14:55] <krit> TabAtkins: this needs two different code pathes
1067. # [14:55] <fantasai> TabAtkins^: Use SVG paint servers as CSS images
1068. # [14:55] <krit> TabAtkins: Is the SVG file referencing an resource, paint sserver or element
1069. # [14:56] <krit> TabAtkins: but depndent on the context, the file needs to be treated differently
1070. # [14:56] * Joins: mjs (~mjs@public.cloak)
1071. # [14:56] <krit> TabAtkins: this might be a problem in more impementation
1072. # [14:56] <krit> TabAtkins: that's why he want to know on parse time which code pah we need
1073. # [14:57] <fantasai> TabAtkins: On mailing list, roc has proposal we're working through on how to segregate SVG references based on structure of frag id as to whether it's a paint server or ?
1074. # [14:57] <krit> TabAtkins: roc has a proposal to differ the file interpretation on #
1075. # [14:57] <fantasai> TabAtkins: If it's a frag id, assume it's a paint server
1076. # [14:57] <fantasai> TabAtkins: If it's a media fragment or SVG functional notation, it's a [picture]
1077. # [14:57] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
1078. # [14:57] <fantasai> ChrisL: What if you have a normal fragment ID that points to an SVGView element?
1079. # [14:58] <fantasai> s/picture/SVG view/
1080. # [14:58] * Joins: yamaday (~yamaday@public.cloak)
1081. # [14:58] <fantasai> TabAtkins: ... use :target pseudo-class to get similar facts
1082. # [14:58] <fantasai> TabAtkins: Probably safe to shut that down
1083. # [14:58] <fantasai> TabAtkins: Let's discuss this soon, decide on something that's good for SVG, and incorporate here.
1084. # [14:58] <fantasai> TabAtkins: If you're interested in this, contribute to mailing list thread on www-style
1085. # [14:59] * Joins: ChrisL (clilley@public.cloak)
1086. # [15:00] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html
1087. # [15:00] <TabAtkins_> Relevant thread: http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html
1088. # [15:00] <fantasai> SteveZ: Appears to me you wnat to distinguish paint servers, things that SVG can fill
1089. # [15:00] <dbaron> http://lists.w3.org/Archives/Public/www-svg/2012Oct/thread.html#msg19
1090. # [15:00] <fantasai> SteveZ: my experience is that heuristics is a fragile way to distinguish
1091. # [15:01] <fantasai> SteveZ: Why not add something to referencing mechanism?
1092. # [15:01] <dbaron> looks like the first few messages on the thread were www-svg only, then it was both www-svg and www-style for the rest
1093. # [15:01] <fantasai> TabAtkins: SVG and CSS are already ambiguous in how they handle this
1094. # [15:01] <fantasai> TabAtkins: Luckily way SVG uses CSS URLs is usually referring to a paint server
1095. # [15:01] <fantasai> TabAtkins: So works already
1096. # [15:01] <fantasai> krit: SVGStack
1097. # [15:02] <fantasai> TabAtkins: mechanism for spriting SVG, using :target to hide everything else
1098. # [15:02] <fantasai> TabAtkins: These would break, because need to load those as an image, not as a paint server
1099. # [15:02] <fantasai> TabAtkins: But afaict the uses of these in the wild are in <object> tags, etc.
1100. # [15:02] <fantasai> krit: we've seen a lot of blog posts and bug reports complaining that we don't implement this
1101. # [15:03] <ed> TabAtkins: yes, that's true, but the use outside of CSS doesn't use the url()-notation, so it's different
1102. # [15:03] <ed> use of svg stacks that is
1103. # [15:03] <fantasai> fantasai: We have several functions that allow referencing images
1104. # [15:04] <fantasai> fantasai: Distinguish based on that
1105. # [15:04] <fantasai> TabAtkins: roc suggests element() interprets as paint server, image() as view
1106. # [15:04] <fantasai> fantasai: make url() do the legacy thing
1107. # [15:04] <fantasai> TabAtkins: both are legacy things
1108. # [15:04] * fantasai is confused
1109. # [15:05] * Quits: chsiao (~chatzilla@public.cloak) (Ping timeout: 20 seconds)
1110. # [15:05] <fantasai> plinss: Interpreting things differently based on fragment ID is an architectural faux-pas
1111. # [15:05] <fantasai> plinss: Interpretation of frag ID should be registered with media type
1112. # [15:05] <fantasai> plinss: Let's not do something that breaks the Web architecture
1113. # [15:05] <fantasai> TabAtkins: Two legacy behaviors are bg-image: url(svg); treats as an image
1114. # [15:06] <fantasai> TabAtkins: fill: url(svg); treats as a paint server
1115. # [15:06] <fantasai> fantasai: Then per-property, define handling of url() per property
1116. # [15:07] <fantasai> TabAtkins: doesn't work for masking -- could load svg as a mask path, or as an image
1117. # [15:07] <fantasai> fantasai: So pick a default, and then can use other function names to do something different
1118. # [15:07] <fantasai> ChrisL: ...
1119. # [15:07] <fantasai> krit: Mozilla also has to consider CORS, which is one reason need to know ahead of time
1120. # [15:07] * ChrisL sigh
1121. # [15:08] * fantasai missed ChrisL's comment
1122. # [15:08] * fantasai invites ChrisL to type it in
1123. # [15:08] <fantasai> krit: So let's leave this issue open for now
1124. # [15:08] <fantasai> krit: Can we publish a FPWD with changes we resolved today?
1125. # [15:08] <fantasai> plinss: any objections?
1126. # [15:08] <ChrisL> ChrisL: why not add a keyword with several values, he initial value is auto which means do the magic thing but you can add specific keywords for paint server or image if auto does the wrong thing for you
1127. # [15:08] <fantasai> RESOLVED: FPWD Masking
1128. # [15:09] <fantasai> plinss: Have similar issue wrt shortname
1129. # [15:09] <fantasai> ...
1130. # [15:09] <fantasai> TabAtkins: It's a Level 1 spec
1131. # [15:10] <fantasai> TabAtkins: So could just call it css-mask
1132. # [15:10] <fantasai> RESOLVED: call it css-mask
1133. # [15:10] <TabAtkins_> dbaron: (to ChrisL) we already have the image()/element() functions to distinguish them, so I don't think we need further keywords to distinguish
1134. # [15:10] * Quits: kensaku (~kensaku@public.cloak) ("Leaving...")
1135. # [15:10] * Joins: kensaku (~kensaku@public.cloak)
1136. # [15:10] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
1137. # [15:11] * Quits: divya (~Adium@public.cloak) ("Leaving.")
1138. # [15:11] <cabanier> slides for blending discussion: http://cabanier.github.com/blending/#/
1139. # [15:11] * Quits: glazou (~glazou@public.cloak) (glazou)
1140. # [15:11] <fantasai> <br duration=22m>
1141. # [15:11] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
1142. # [15:11] * Joins: cabanier (~cabanier@public.cloak)
1143. # [15:11] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
1144. # [15:11] * Joins: rotsuya (~rotsuya@public.cloak)
1145. # [15:12] * leaverou is now known as leaverou_away
1146. # [15:12] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 20 seconds)
1147. # [15:14] * Quits: sakkuru (~sakih@public.cloak) (Ping timeout: 20 seconds)
1148. # [15:18] * Quits: Norbert (~Norbert@public.irc.w3.org) (Ping timeout: 20 seconds)
1149. # [15:19] * Quits: stearns (~anonymous@public.cloak) (stearns)
1150. # [15:19] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) (Ping timeout: 20 seconds)
1151. # [15:21] * Joins: sakkuru (~sakih@public.cloak)
1152. # [15:23] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
1153. # [15:26] * Parts: Jirka (~jirka@public.cloak) (Jirka)
1154. # [15:29] * Joins: stearns (~anonymous@public.cloak)
1155. # [15:29] * Quits: florianr (~yaaic@public.cloak) ("")
1156. # [15:31] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
1157. # [15:31] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
1158. # [15:32] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
1159. # [15:34] * Joins: tomoyuki (~tshimizu3@public.cloak)
1160. # [15:36] * leaverou_away is now known as leaverou
1161. # [15:37] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
1162. # [15:37] * Joins: cabanier (~cabanier@public.cloak)
1163. # [15:39] * Joins: divya (~Adium@public.cloak)
1164. # [15:40] * Joins: glazou (~glazou@public.cloak)
1165. # [15:40] <cabanier> http://cabanier.github.com/blending/#/
1166. # [15:40] <TabAtkins_> Topic: Compositing
1167. # [15:41] <TabAtkins_> cabanier: Blending spec currently says that blending/compositing always happens in a non-isolated group. I propose that they happen in an isolated group.
1168. # [15:41] * krit The question for scribes get more and more rhetoric
1169. # [15:41] <TabAtkins_> cabanier: Two reasons - non-isolated are much more expensive to do.
1170. # [15:42] <TabAtkins_> cabanier: Two, some OS frameworks (such as Cairo) can't do them natively, so they'd have to be done by hand.
1171. # [15:42] <TabAtkins_> cabanier: So I fear that they would be non-implementable as written today.
1172. # [15:46] <TabAtkins_> cabanier: [goes through his slides]
1173. # [15:47] <TabAtkins_> cabanier: So in isolated groups, as soon as you have a stacking context, the elements in there only blend/composite with each other, not with elements outside the stacking context.
1174. # [15:47] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
1175. # [15:47] <TabAtkins_> cabanier: (in SVG, the relevant group is the <g> element)
1176. # [15:48] <TabAtkins_> cabanier: Authors generally *prefer* non-isolated groups, but the implementability just seems to be too painful right now.
1177. # [15:48] <TabAtkins_> TabAtkins_: So we might still want to have a proeprty that merges groups?
1178. # [15:48] * Joins: tomoyuki (~tshimizu3@public.cloak)
1179. # [15:49] <TabAtkins_> cabanier: Already exists. I'm just asking to change the default.
1180. # [15:49] <TabAtkins_> cabanier: (Also, that property probably won't be implemented yet, and may be removed from this level.)
1181. # [15:50] <TabAtkins_> cabanier: I know some of the graphics people will be unhappy, but they can work around it by putting things in the same stacking context.
1182. # [15:51] <TabAtkins_> cabanier: This weirdness already exists sometimes - z-index can be disrupted by opacity creating a new stack.
1183. # [15:51] * hober an oldie but a goodie: http://w3cmemes.tumblr.com/post/22708671971
1184. # [15:51] <TabAtkins_> TabAtkins_: Relevant Moz implementor would be roc, right?
1185. # [15:52] <TabAtkins_> krit: Cairo was cited as the problem. Direct3d will have the same problem.
1186. # [15:52] <TabAtkins_> lstorset: Will this affect existing SVG impls?
1187. # [15:52] <TabAtkins_> cabanier: It's a new property, so no.
1188. # [15:53] * Joins: rotsuya (~rotsuya@public.cloak)
1189. # [15:53] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 20 seconds)
1190. # [15:53] <TabAtkins_> RESOLVED: Turn the Compositing default to be isolated groups.
1191. # [15:54] * Joins: chsiao (~chatzilla@public.cloak)
1192. # [15:54] <TabAtkins_> dino: What about publishing the spec?
1193. # [15:54] <TabAtkins_> cabanier: It's already a WD.
1194. # [15:54] <TabAtkins_> cabanier: And I'll request a new WD when I make edits.
1195. # [15:54] <TabAtkins_> Topic: Animations
1196. # [15:55] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 20 seconds)
1197. # [15:56] <TabAtkins_> sylvaing: What do we do for TTA? Something every week?
1198. # [15:56] <TabAtkins_> plinss: If there are issues, our policy is to bring them up. We just confirmed through prioritization that TTA is our top priorities, so they'll get interrupt priority.
1199. # [15:56] * Joins: yamaday (~yamaday@public.cloak)
1200. # [15:56] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 20 seconds)
1201. # [15:56] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713
1202. # [15:57] <TabAtkins_> sylvaing: This is about dynamic changes to animation properties or keyframes.
1203. # [15:57] <TabAtkins_> sylvaing: Spec since the beginning requires animation property or keyframes to be snapshotted at the start of the animation.
1204. # [15:57] <TabAtkins_> sylvaing: David and Simon agree that it should be more open to dynamic changes while it's running, such as changing the duration.
1205. # [15:57] <TabAtkins_> sylvaing: We haven't defined in detail how that works.
1206. # [15:58] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
1207. # [15:58] * Quits: yaso (~yaso@public.cloak) (yaso)
1208. # [15:58] <TabAtkins_> dbaron: I believe FF's model is that, at the first moment in which the animation-name appears in the animation list, we determine the start-time for the animation.
1209. # [15:58] <TabAtkins_> dbaron: This is the start time at the end of the delay (I think).
1210. # [15:58] <TabAtkins_> dbaron: As long as that animation name stays in th elist of animations, that's the start time we use for the animation.
1211. # [15:58] <TabAtkins_> dbaron: And we continue using that start time for all other things.
1212. # [15:59] <TabAtkins_> dbaron: I think basically anything else can change.
1213. # [15:59] <TabAtkins_> dbaron: So I *think* if you change the delay it has no effect, because we compute the "start" time as the end of the delay.
1214. # [15:59] <TabAtkins_> dbaron: But I'd have to confirm.
1215. # [15:59] * Joins: lstorset (~leif@public.cloak)
1216. # [16:00] <TabAtkins_> dbaron: Effectively, you just recompute all the parametersof the animation at every moment based on the current values.
1217. # [16:00] <ChrisL> all the parameters are recomputed at each tick in the animation
1218. # [16:00] * Quits: Reinaldo_ (~Reinaldo@public.irc.w3.org) (Ping timeout: 20 seconds)
1219. # [16:00] <TabAtkins_> dbaron: Exception is pausing. When running->paused, record the time you paused. Switch from paused->running, adjust the start time forward by the amount of time it was paused.
1220. # [16:01] <TabAtkins_> plinss: if you change things while paused, it can put you in a different position?
1221. # [16:02] <TabAtkins_> dbaron: Yes. Change the animation-duration while it's paused, and it'll live-move you to the new position.
1222. # [16:02] <TabAtkins_> dino: I don't like starting it at the end of the delay.
1223. # [16:03] <TabAtkins_> dbaron: I agree - I probably should have made it record from the start of the delay instead, so it can take delay changes into account.
1224. # [16:03] <TabAtkins_> dino: We snapshot right now, but the underlying engine supports modification.
1225. # [16:03] <TabAtkins_> dino: We have all the infrastructure so we can expose it to JS.
1226. # [16:04] <TabAtkins_> sylvaing: I'm okay with making the animation properties dynamic.
1227. # [16:04] * Joins: mishida (~mishida@public.irc.w3.org)
1228. # [16:04] <TabAtkins_> sylvaing: We need some prose in the spec to b emore explicit.
1229. # [16:04] * Joins: Norbert (~standards@public.cloak)
1230. # [16:04] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
1231. # [16:05] <TabAtkins_> sylvaing: For example, "animation-name: b, c, d; animation-duration: 2s, 3s, 4s;", then I change to "animation-name: a, b, c, d;", does it restart b, c, d, or does it consider them as having never left the animation list?
1232. # [16:05] * Joins: hiroki (hiroki@public.cloak)
1233. # [16:05] <TabAtkins_> dbaron: b,c,d never left the lsit.
1234. # [16:05] <TabAtkins_> sylvaing: Okay, we need that written down.
1235. # [16:06] <TabAtkins_> dbaron: I wonder what brian birtle thinks about this, given his work.
1236. # [16:06] <TabAtkins_> TabAtkins_: Based on me working with him, I think this is in line with what he wants.
1237. # [16:07] <TabAtkins_> dino: Further wrinkles. What happens if your animation is almost done, you shrink its duration so it's already over? Do you get an end event?
1238. # [16:07] <TabAtkins_> TabAtkins_: I think *not* delivering one would result in bad accidental bugs.
1239. # [16:07] * Joins: knobuta2 (~knobuta2@public.irc.w3.org)
1240. # [16:08] <TabAtkins_> dino: Okay, further answer. Animations with many iterations. Just befor ethe first iteration ends, you shrink the duration so that the entire animatino is over. Do you get tons of iterations events, one after the other?
1241. # [16:08] <TabAtkins_> TabAtkins: I can be argued either way on whether to deliver iteration events that didn't "actually" pass. I think it might be acceptable to have those inconsistent.
1242. # [16:08] <TabAtkins_> dino: Okay. So there are multiple things like this that need to be resolved and specified.
1243. # [16:09] <TabAtkins_> sylvaing: Right - right now everything is simple, because they can't change.
1244. # [16:09] <TabAtkins_> dino: We'll have to check every state transition - an animation that is done but filling (still technically running), but then has its duration changed so that it should still be running?
1245. # [16:10] <TabAtkins_> dino: Need to work out the full state machine for all of this.
1246. # [16:10] <TabAtkins_> plinss: (re: iteration events) maybe only deliver the last iteration, updating you to the current state.
1247. # [16:11] <TabAtkins_> ChrisL: Scrubbing was one of the things that SMIL got wrong - time resolution was permanent, so if you scrubbed and then ran it, it would jump back to the time it had gotten itself to.
1248. # [16:12] <TabAtkins_> dbaron: [draws a table of states on the whiteboard]
1249. # [16:12] <TabAtkins_> dbaron: If we define what fires for every transition between these cells, is that sufficient?
1250. # [16:12] <TabAtkins_> dino: Yes.
1251. # [16:12] <TabAtkins_> dino: (But there may be another column or two on that graph.)
1252. # [16:13] <dbaron> columns: before / 1st iter / 2nd iter / 3rd iter / after
1253. # [16:13] <dbaron> rows: running / paused
1254. # [16:13] <dbaron> or maybe
1255. # [16:13] <dbaron> rows: running / paused, happens immediately / paused, happens when unpaused
1256. # [16:13] <TabAtkins_> sylvaing: Okay, so I think there's agreement to make these properties dynamic.
1257. # [16:13] <dbaron> And I think there's agreement that the recorded start is the start before the delay
1258. # [16:14] <TabAtkins_> RESOLUTION: Change the animation properties to be dynamically changable, details TBD.
1259. # [16:14] <TabAtkins_> ACTION sylvain to define what happens when animation properties are changed dynamically.
1260. # [16:14] <oyvind> and @keyframes?
1261. # [16:15] <TabAtkins_> oyvind, getting there.
1262. # [16:15] * ChrisL trackbot, self.reboot()
1263. # [16:15] <oyvind> alright
1264. # [16:15] <TabAtkins_> sylvaing: So, keyframes.
1265. # [16:15] <TabAtkins_> sylvaing: Changing those on the fly while animation is running.
1266. # [16:15] <TabAtkins_> sylvaing: The concept makes sense when the animation iterates - when the next interval takes the changes into account.
1267. # [16:16] <TabAtkins_> sylvaing: If you have an animation that runs once, I dunno.
1268. # [16:16] <TabAtkins_> dino: It sounds testable, sure, but internally it's actually kinda difficult - animation may be running on another thread, and there's a disconnect in processing times.
1269. # [16:17] * Joins: JohnJansen (~JohnJansen@public.cloak)
1270. # [16:17] <TabAtkins_> TabAtkins_: Conceptually, I don't see anything wrong with changing them mid-animation.
1271. # [16:18] <TabAtkins_> glazou: I have a use-case. A long-running webapp animation may have a large duration. If you change it, you don't want to wait for an entire iteration to go by.
1272. # [16:18] * Quits: divya (~Adium@public.cloak) (Client closed connection)
1273. # [16:18] * Joins: divya1 (~Adium@public.cloak)
1274. # [16:18] <TabAtkins_> sylvaing: Are there any animation functions in @keyframes?
1275. # [16:18] <TabAtkins_> TabAtkins_: Only the timing function.
1276. # [16:18] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
1277. # [16:19] <TabAtkins_> glazou: I think that dynamic changes of animations will actually be a reasonably common case (editting is hard right now, but CSSOM will improve)
1278. # [16:19] * divya1 is now known as divya
1279. # [16:21] * Joins: kensaku (~kensaku@public.cloak)
1280. # [16:22] <TabAtkins_> sylvaing: So what about changes of keyframes during an iteration event, intending for the next iteration to use new values?
1281. # [16:22] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
1282. # [16:22] * Joins: kensaku (~kensaku@public.cloak)
1283. # [16:22] <TabAtkins_> TabAtkins_: There may by a delay if you need to deliver the changes to a separate animation thread, but otherwise it should work fine.
1284. # [16:22] <TabAtkins_> TabAtkins_: I think we're doing work on our end that should make it automatically do a smooth transition over to the new values when it discovers that it's overshot and needs to change tracks.
1285. # [16:22] <TabAtkins_> dino: But then we need to specify that.
1286. # [16:23] * Quits: stearns (~anonymous@public.cloak) (Ping timeout: 60 seconds)
1287. # [16:23] <TabAtkins_> TabAtkins_: We'll have non-interop a bit anyway, because of timing issues based on whether you do animatino on a separate thread or not. I think we can leave it alone and spec after things have shaken out.
1288. # [16:23] * Joins: kensaku_ (~kensaku@public.cloak)
1289. # [16:23] <TabAtkins_> RESOLVED: @keyframes can be dynamically changed
1290. # [16:23] <glazou> yay
1291. # [16:24] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15846
1292. # [16:24] <TabAtkins_> sylvaing: Next. Transition events report what pseudo-element of the element the transition is running against.
1293. # [16:24] <TabAtkins_> sylvaing: We don't have it for animation events at the moment.
1294. # [16:24] * Joins: stearns (~anonymous@public.cloak)
1295. # [16:24] <TabAtkins_> dbaron: We should just copy it.
1296. # [16:25] <TabAtkins_> RESOLVED: Copy over the pseudo-element info from transition events to animation events.
1297. # [16:25] * Joins: Rossen (~Rossen@public.cloak)
1298. # [16:25] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0020.html
1299. # [16:25] <TabAtkins_> sylvaing: What happens when you have duplicate animation names in the animation-name property.
1300. # [16:25] <TabAtkins_> sylvaing: Seems that last one wins.
1301. # [16:26] * ChrisL imagines animating font-size on :first-line
1302. # [16:26] * Quits: kensaku (~kensaku@public.cloak) (Ping timeout: 60 seconds)
1303. # [16:26] * Joins: yaso (~yaso@public.cloak)
1304. # [16:26] * Quits: kensaku_ (~kensaku@public.cloak) (Client closed connection)
1305. # [16:27] * Quits: divya (~Adium@public.cloak) ("Leaving.")
1306. # [16:27] * Joins: kensaku (~kensaku@public.cloak)
1307. # [16:27] <TabAtkins_> dbaron: I think we resolved that and I edited it already.
1308. # [16:27] * SimonSapin is glad not to implement that
1309. # [16:27] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) ("TakIRC")
1310. # [16:27] <TabAtkins_> dbaron: A similar thing is which animation property's length is the winner. I propose that animation-name define the number of animations, and every other property gets padded/clipped to that length.
1311. # [16:28] <TabAtkins_> dbaron: This matches what backgrounds/etc do.
1312. # [16:28] <TabAtkins_> dbaron: I may have already editted this into the draft.
1313. # [16:28] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
1314. # [16:28] * Joins: divya (~Adium@public.cloak)
1315. # [16:29] * Joins: smfr (~smfr@public.cloak)
1316. # [16:29] <TabAtkins_> RESOLVED: animation-name's length is authoritative. Other animations properties are adjusted to its length.
1317. # [16:29] <TabAtkins_> ACTION Sylvain to make sure that animation-name's length is definitive, and edit it to be so otherwise.
1318. # [16:30] * Quits: Norbert (~standards@public.cloak) (Norbert)
1319. # [16:30] <TabAtkins_> RESOLVED: When you encounter duplicate animations names, last one wins.
1320. # [16:30] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
1321. # [16:30] <oyvind> that last resolution seems unclear
1322. # [16:31] * Joins: kensaku (~kensaku@public.cloak)
1323. # [16:31] * Joins: dbaron (~dbaron@public.cloak)
1324. # [16:31] <glazou> oyvind: explain ?
1325. # [16:31] <oyvind> current draft says that the last wins *at any particular point in time, for a particular property*
1326. # [16:31] <dbaron> http://dev.w3.org/csswg/css3-animations/#list-matching already has the first of those two resolutions edited in, actually
1327. # [16:31] <TabAtkins_> oyvind, when assembling the set of property values that define the animation, the index of the last occurence of the animation name is what is used.
1328. # [16:32] <dbaron> oyvind, oh, it's about what happens if the same animation-name is specified twice in the list
1329. # [16:32] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14599
1330. # [16:32] <dbaron> oyvind, which duration, delay, timing-function, etc., does it use
1331. # [16:32] * glazou oyvind: 'animation-name: foo foo"
1332. # [16:32] <sylvaing> http://jsfiddle.net/leaverou/jwHva/2/
1333. # [16:32] <dbaron> oyvind, the answer is that it's the last occurrence of that animation-name in the list
1334. # [16:33] <TabAtkins_> sylvaing: In this example, if you remove border-style:solid, the animation stops working.
1335. # [16:33] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Oct/0834.html
1336. # [16:34] <TabAtkins_> dbaron: I think I wrote a response for why this is crazy.
1337. # [16:35] * Quits: yaso (~yaso@public.cloak) (yaso)
1338. # [16:36] <TabAtkins_> TabAtkins_: The reason why it's problematic is that border-style is not animatable. Thus, since the default (pre-animation) value of border-style is none, the animatino doesn't change it to solid. And, since it's "none", the border-width computes to 0, and so no animation happens at all.
1339. # [16:36] <oyvind> dbaron, ok, I misunderstood somewhat
1340. # [16:36] <TabAtkins_> leaverou: Authors find this super-confusing in my experience.
1341. # [16:36] <TabAtkins_> dbaron: There's an even more subtle issue here.
1342. # [16:36] <TabAtkins_> dbaron: Related to the processing model.
1343. # [16:36] * Joins: florianr (~yaaic@public.cloak)
1344. # [16:37] <TabAtkins_> dbaron: When animating from A to B, there's an idea that it overrides some of the properties, and only those.
1345. # [16:37] <TabAtkins_> dbaron: So this animation actually overrides 13 properties. border-image, border-top-style, border-top-color, etc.
1346. # [16:37] <TabAtkins_> dbaron: For each keyframe, you get a computed value from it, and then you animate the computed values between.
1347. # [16:38] <TabAtkins_> dbaron: However, in some cases, for border-width, the computed value depends on border-style.
1348. # [16:38] <TabAtkins_> dbaron: Which value are you using? The base value, or the value that the keyframe is overriding?
1349. # [16:38] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
1350. # [16:38] <TabAtkins_> dbaron: And this gets more confusing.
1351. # [16:39] <TabAtkins_> dbaron: Say you have a 50% keyframe here with only a "border-width: 10px;" property.
1352. # [16:39] <TabAtkins_> dbaron: What border-style is this resolved against?
1353. # [16:39] * Quits: knobuta2 (~knobuta2@public.irc.w3.org) ("Page closed")
1354. # [16:39] * Joins: knobuta2 (~knobuta2@public.irc.w3.org)
1355. # [16:39] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
1356. # [16:39] <TabAtkins_> dbaron: Gecko currently resolves it against the base value.
1357. # [16:40] <TabAtkins_> dbaron: (It also does this for the other keyframes.)
1358. # [16:40] <TabAtkins_> dbaron: The spec's processing model just doesn't really care about the fact that computed values can depend on other computed values.
1359. # [16:41] * Joins: dbaron (~dbaron@public.cloak)
1360. # [16:41] <TabAtkins_> dbaron: I think it should, but I doubt any browser really does it.
1361. # [16:41] <TabAtkins_> dbaron: I think a testcase that covers only the issue I was talking about would be one that animates font-size and some length in ems.
1362. # [16:43] * Quits: florianr (~yaaic@public.cloak) ("")
1363. # [16:43] * Joins: Norbert (~standards@public.cloak)
1364. # [16:45] <TabAtkins_> ChrisL: In SMIL anything can be animated. It just switch halfway through.
1365. # [16:45] <dbaron> dbaron: halfway through the timing function (which makes step-start and step-end magically work)
1366. # [16:46] <TabAtkins_> TabAtkins_: Worst case, can we separate this out, so that non-animatable properties with constant value are still paid attention to and "animate".
1367. # [16:46] <TabAtkins_> ChrisL: That sounds like doing 3/4 of the work and just stopping.
1368. # [16:46] <TabAtkins_> glazou: We could also just say non-animatable properties freeze at their first keyframe value.
1369. # [16:47] <dbaron> dbaron: The thing about font-size and length in ems -- need to test with both in-the-same-@keyframes and in-different-@keyframes
1370. # [16:47] <TabAtkins_> dbaron: Regarding font-size and length in ems, make sure you test both when the two proeprties are in the same keyframe, and when they're not.
1371. # [16:48] <dbaron> ... and in different @keyframes on different elements.
1372. # [16:48] <TabAtkins_> TabAtkins_: So 3 cases of increasing complexity.
1373. # [16:49] <TabAtkins_> glazou: So what about my "freeze at frame 0" idea?
1374. # [16:50] <TabAtkins_> dbaron: I think that has a higher chance of web compat problems.
1375. # [16:50] <TabAtkins_> dbaron: The problem with all of these is potential web compat.
1376. # [16:51] <TabAtkins_> glazou: Can we seriously not do better than just making this work?
1377. # [16:51] <ChrisL> I'm arguing for fixing it now by defining animation of enumerated values
1378. # [16:52] <TabAtkins_> ChrisL: Are you saying that people are relying on the behavior in that fiddle?
1379. # [16:52] <TabAtkins_> dbaron: I don't know.
1380. # [16:52] <TabAtkins_> dbaron: Webdevs often try things, find they don't work, and then don't remove them.
1381. # [16:52] * Quits: toms (~chatzilla@public.cloak) ("ChatZilla 0.9.88.2 [Firefox 10.0.4/20120420145309]")
1382. # [16:53] <TabAtkins_> ChrisL: So if we fix it, something might suddenly start working and break a page.
1383. # [16:53] <TabAtkins_> dbaron: I suspect we could get away with making this change in animations.
1384. # [16:53] <TabAtkins_> dbaron: I suspect not in transitions, because it defaults to "all".
1385. # [16:54] <TabAtkins_> dbaron: I suspect that if we fix it, we're adding a minimum of 4 months to the spec.
1386. # [16:54] <TabAtkins_> ChrisL: Yes, but that avoids 3+ years of us explaining why it's stupid.
1387. # [16:54] <TabAtkins_> dino: I don't think many authors have hit this particular case. Or they do and they screw around until it works.
1388. # [16:55] <sylvaing> cool border transitions: http://thecodeplayer.com/walkthrough/simple-yet-amazing-css3-border-transition-effects
1389. # [16:56] <TabAtkins_> leaverou: I think this change's impact will be smaller than gradient angles flipping. ^_^
1390. # [16:56] <TabAtkins_> dino: I'd like to get some compat data on this first.
1391. # [16:56] <TabAtkins_> TabAtkins_: Can we put a time limit on this?
1392. # [16:56] * Joins: mollydotcom (~mollydotcom@public.irc.w3.org)
1393. # [16:57] <TabAtkins_> dbaron: Do you know why Gecko doesn't allow you to style the color of the radio button dot?
1394. # [16:58] <TabAtkins_> dbaron: Because hotmail.com styled all their radio buttons with "background-color: green; color: green;", presumably on the theory that *one* of them would work.
1395. # [16:59] <TabAtkins_> TabAtkins_: Okay, so suggestion is this: Allow all properties (except maybe animation properties) to be animatable. Discrete properties swap their values halfway through the transition function (to match SMIL).
1396. # [16:59] <dbaron> (doesn't apply to transitions)
1397. # [16:59] <dbaron> s/transition function/timing function/
1398. # [17:01] <TabAtkins_> dino: I don't object to putting this in the spec, but would then like time to investigate compat.
1399. # [17:01] * Joins: plh (plehegar@public.cloak)
1400. # [17:02] * Bert thinks that leaves a small pb to decide at 50%: '0% {border: 10px solid} 50% {border-width: 5px} 100% {border: 0px none}' is the border already none at 50% or only at 50.00001% ?
1401. # [17:03] <dbaron> depending on whether timing function output is greater or less than 0.5
1402. # [17:03] <TabAtkins_> leaverou: If you have cubic-bezier with out-of-range params, you can have it hit 50% multiple times. What happens there?
1403. # [17:03] <dbaron> so it might swap more than once
1404. # [17:03] <dbaron> (though we don't think so)
1405. # [17:03] <TabAtkins_> dbaron: It takes the first/last value depending on whether progress is currently above/below 50%, so it'll flip multiple times.
1406. # [17:04] <leaverou> example of timing function that reaches 50% multiple times: http://cubic-bezier.com/#0,1.8,1,-0.79
1407. # [17:04] <TabAtkins_> RESOLVED: Make *animations* transition *all* properties. Unless otherwise specified, properties take their starting values below 50% timing function progress, and end values above 50% timing function progress.
1408. # [17:04] <dbaron> cubic-bezier(0.25, 3, 0.75, -2)
1409. # [17:05] <dbaron> (you can cross 50% more than once)
1410. # [17:05] * leaverou dbaron that's what I just said :)
1411. # [17:05] <Bert> q+ to ask if we can now remove the Animatable line from table.propdef.
1412. # [17:05] * Zakim sees Bert on the speaker queue
1413. # [17:06] <dbaron> Bert, no, we can't
1414. # [17:06] <dbaron> q+ to go back to the processing model issue
1415. # [17:06] * Zakim sees Bert, dbaron on the speaker queue
1416. # [17:07] <glazou> http://www.w3.org/2012/10/TPAC/meetup-Lyon.html#logistics
1417. # [17:07] <dino> leaverou, is that your site? cubic-bezier.com?
1418. # [17:07] * leaverou is now known as leaverou_away
1419. # [17:08] <TabAtkins_> ack bert
1420. # [17:08] <Zakim> Bert, you wanted to ask if we can now remove the Animatable line from table.propdef.
1421. # [17:08] * Zakim sees dbaron on the speaker queue
1422. # [17:08] <TabAtkins_> dbaron: No, really it's about how to interpolate the property.
1423. # [17:09] * Quits: divya (~Adium@public.cloak) (Ping timeout: 60 seconds)
1424. # [17:09] <dbaron> we could maybe rename Animatable: to Interpolation:
1425. # [17:09] <dbaron> ack dbaron
1426. # [17:09] <Zakim> dbaron, you wanted to go back to the processing model issue
1427. # [17:09] * Zakim sees no one on the speaker queue
1428. # [17:09] <plinss> ack dbaron
1429. # [17:09] * Zakim sees no one on the speaker queue
1430. # [17:10] <TabAtkins_> dbaron: Do we at least have an issue filed on the processing model stuff we're discussing?
1431. # [17:10] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
1432. # [17:10] <TabAtkins_> dbaron: How you compute the base values for the properties that we were discussing a moment ago?
1433. # [17:10] * Quits: chsiao (~chatzilla@public.cloak) ("ChatZilla 0.9.89 [Firefox 16.0.2/20121025205401]")
1434. # [17:10] * Quits: Kid (~Kid@public.cloak) ("Leaving...")
1435. # [17:11] <TabAtkins_> ACTION tab to test the processing model of animations where computed values of animated properties depend on each other.
1436. # [17:11] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
1437. # [17:13] * hober ok, smfr, you're up
1438. # [17:13] <krit> https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271
1439. # [17:13] <fantasai> ScribeNick: fantasai
1440. # [17:13] * Quits: Norbert (~standards@public.cloak) (Norbert)
1441. # [17:14] * hober plinss: would you please project http://jsfiddle.net/fNxAQ/1/ for smfr?
1442. # [17:14] <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328
1443. # [17:14] <fantasai> smfr: We think that the only real substantive issue in the transforms spec is this bug
1444. # [17:15] <fantasai> smfr: which talks about the containing block terminology used in 3D transforms rendering part of the spec
1445. # [17:15] <smfr> http://jsfiddle.net/fNxAQ/3/
1446. # [17:15] <fantasai> smfr: and to illustrate that, jsfiddle that Ted just linked to, hopefully someone can project
1447. # [17:15] <fantasai> smfr: The issue here is related to 3D rendering contexts and
1448. # [17:15] <fantasai> smfr: how 3D transforms propagate across containing blocks,
1449. # [17:15] * Joins: SimonSapin (~yaaic@public.cloak)
1450. # [17:15] <fantasai> smfr: Is that jsfiddle on the screen?
1451. # [17:15] * Quits: SimonSapin (~yaaic@public.cloak) (Client closed connection)
1452. # [17:15] <fantasai> [yes]
1453. # [17:16] * Joins: SimonSapin (~yaaic@public.cloak)
1454. # [17:16] <fantasai> [fiddling with example]
1455. # [17:17] <fantasai> smfr: 2 containers here,
1456. # [17:17] <SimonSapin> Sorry to early, going to the city hall to prepare talks
1457. # [17:17] <fantasai> smfr: border box with perspective
1458. # [17:18] <fantasai> smfr: Top intemrediate div with no style
1459. # [17:18] <fantasai> smfr: ... with rotate-y
1460. # [17:18] * Quits: mishida (~mishida@public.irc.w3.org) (Ping timeout: 60 seconds)
1461. # [17:18] <fantasai> smfr: issue here is whether perspective on grandparent affects rendering of that transform
1462. # [17:18] <fantasai> smfr: i.e. whether the intermediate box flattens it
1463. # [17:18] <fantasai> smfr: i.e. whether the intermediate and the box are members of the same 3D context
1464. # [17:18] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) (Ping timeout: 60 seconds)
1465. # [17:18] <fantasai> smfr: I believe in FF, intermediate box causes flattening to occur, b/c it's the containing block of the blue box
1466. # [17:19] <fantasai> smfr: in Webkit it doesn't
1467. # [17:19] <fantasai> smfr: FF more close to wording in current spec
1468. # [17:19] <fantasai> smfr: Transforms looks at containing block hierarchy
1469. # [17:19] <fantasai> smfr: in bottom example, container, then inside an image, and image has a block sibling
1470. # [17:19] <fantasai> smfr: image gets an anonymous block container
1471. # [17:19] <fantasai> smfr: in this case the containing block for the image is anonymous
1472. # [17:19] <fantasai> smfr: question here is whether that anon box prevents transform
1473. # [17:20] <fantasai> smfr [... gecko]
1474. # [17:20] <krit> http://jsfiddle.net/fNxAQ/6/
1475. # [17:20] <fantasai> dbaron: Gecko doesn't actually create an anonymous box here
1476. # [17:21] <fantasai> [fantasai explains what gecko does, why it doesn' tmake that box]
1477. # [17:21] * hober plinss: updated jsfiddle link above
1478. # [17:21] <fantasai> smfr: implementation does't matter much; but if you adhere to strict wording of spec, there's an anon box that's your containing block
1479. # [17:21] <fantasai> smfr: Webkit's implementation is falling out of some other things going on
1480. # [17:21] <fantasai> smfr: Detail is something like we're looking at ancestors that are transformed or that are positioned or that have other properties that create stacking contexts
1481. # [17:22] <fantasai> smfr: So it's not conforming to the spec, and not always predictable
1482. # [17:22] <fantasai> dbaron: You say you're looking for ancestors starting ...
1483. # [17:22] <fantasai> dbaron: starting from thing that has a 3D transform?
1484. # [17:22] <fantasai> smfr: Any of those things between that and the transform will cause flattening to occur
1485. # [17:23] <fantasai> smfr: so webkit won't flatten otherwise
1486. # [17:23] <krit> Zakim, q+
1487. # [17:23] <Zakim> I see krit on the speaker queue
1488. # [17:23] <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
1489. # [17:23] <fantasai> smfr: wording in spec is very tight, maybe need something in between
1490. # [17:23] <fantasai> smfr: Aryeh suggests defining a new type of container called transform parent, and then make a list of things that make something a transform parent
1491. # [17:23] <fantasai> smfr: [quotes]
1492. # [17:24] <fantasai> smfr: [...]
1493. # [17:24] <fantasai> smfr: Aryeh's suggestion.. A is closer to what authors expect, and B doesn't have anon containing block problem
1494. # [17:25] <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c0
1495. # [17:25] * Joins: koji (~koji@public.cloak)
1496. # [17:25] <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
1497. # [17:25] <fantasai> smfr: Jsut got browser shots from IE10
1498. # [17:25] <fantasai> smfr: Which is similar to FF behavior
1499. # [17:25] <fantasai> smfr: Opera shot didn't show any support for 3D transforms
1500. # [17:26] <fantasai> smfr: Question here is whether we try to cook up some wording similar to Aryeh's suggestion
1501. # [17:26] <fantasai> smfr: or whta
1502. # [17:26] <fantasai> smfr: input from other implementers
1503. # [17:27] <fantasai> [...]
1504. # [17:27] <fantasai> sylvaing: Our rendering in this case is not really related
1505. # [17:27] <sylvaing> s/is not/may not be
1506. # [17:27] <fantasai> krit: Do we want to follow Webkit, or different approach?
1507. # [17:28] <fantasai> fantasai: Seems to me that webkit's behavior is closer to what authors want; wouldn't want everything to flatten all the time, right?
1508. # [17:28] * Joins: mishida (~mishida@public.irc.w3.org)
1509. # [17:28] <fantasai> dbaron: Authoring perspective, want it never to flatten, but problem is it's too expensive.
1510. # [17:28] <fantasai> smfr: Want it to flatten in certain cases
1511. # [17:28] <fantasai> dbaron: You'd want the default to be the other way around
1512. # [17:29] <fantasai> smfr: when we were designing this transform property, did think it would be good to not flatten always, but didn't do that b/c thought it would be fairly significant change to CSS
1513. # [17:29] <fantasai> smfr: Webpages are typically flatt, and having them not-flat would be strange
1514. # [17:29] <fantasai> smfr: That's why default style is to be flat
1515. # [17:29] <dbaron> those two lines from me were questions
1516. # [17:29] <fantasai> smfr: Time authors use preserve3d is when they build up 3d hierarchies of objects they want to sit in the same perspective
1517. # [17:30] <fantasai> smfr: It's fairly unusual for someone to put perspective on document and expect theo whole thing to be 3d
1518. # [17:30] <fantasai> smfr: Generally have islands of 3D
1519. # [17:30] <fantasai> smfr: So we expect authors to sprinkle around preserve3d between things with perspective and objects they want to show in 3d
1520. # [17:30] <fantasai> smfr: not too bad, usually only 1-3 levels of elements in between
1521. # [17:30] <fantasai> dbaron: Substantive implementation differences. If we pick a different rule, would it be more burdensome?
1522. # [17:31] <fantasai> smfr: I think a rule like Aryeh's it'd be a little work for us, but not too bad. Have to flatten a little more than we're doing
1523. # [17:31] <fantasai> smfr: The obvious flaw with using contianing block in case where you have an anon containing block, there's no way author can style that to make it preserve3d
1524. # [17:31] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
1525. # [17:31] <fantasai> dbaron: Other reason bz pointed out is that containing block is not an element, it's a rectangle
1526. # [17:31] <fantasai> smfr: didn't anton fix some things wrt that?
1527. # [17:31] <fantasai> antonp: yep, but nothing published yet
1528. # [17:32] <fantasai> antonp: but could work around that, if that's what you want
1529. # [17:32] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
1530. # [17:32] <fantasai> smfr: If no one has any more input, then action is on me to write up wording for spec ~ Aryeh's comment #4
1531. # [17:32] * Quits: mjs (~mjs@public.cloak) (mjs)
1532. # [17:32] <dbaron> sounds good to me
1533. # [17:33] <fantasai> krit: Can we resolve on some kind of wording ?
1534. # [17:33] <fantasai> plinss: Do we have wording?
1535. # [17:33] <fantasai> dbaron: Simon was proposing to take an action to propose wording
1536. # [17:33] <fantasai> ACTION smfr: propose wording for 3d perpsective containing block thing
1537. # [17:33] * RRSAgent records action 2
1538. # [17:34] * Joins: lmclister (~lmclister@public.irc.w3.org)
1539. # [17:34] <fantasai> RESOLVED: Accept Aryeh's proposal, exact wording TBD
1540. # [17:34] * Joins: divya (~divya@public.irc.w3.org)
1541. # [17:34] <krit> https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271
1542. # [17:34] <fantasai> krit: Some other items on issues list
1543. # [17:34] <fantasai> krit: Did some wording on it, but needs review from implementers
1544. # [17:34] <fantasai> krit: Not necessarily an issue, but should be reviewed
1545. # [17:35] * Joins: mjs (~mjs@public.cloak)
1546. # [17:35] * Quits: koji (~koji@public.cloak) (Ping timeout: 60 seconds)
1547. # [17:35] <fantasai> ACTION sylvain: look into bug 15605
1548. # [17:35] * RRSAgent records action 3
1549. # [17:36] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
1550. # [17:36] <fantasai> dbaron: I truest Aryeh on this
1551. # [17:36] <dbaron> s/truest/trust/
1552. # [17:37] <fantasai> dean: We're happy with this
1553. # [17:37] * Quits: SimonSapin (~yaaic@public.cloak) (Ping timeout: 60 seconds)
1554. # [17:37] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
1555. # [17:37] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17017
1556. # [17:37] <fantasai> krit: Next issue is concern of dbaron's
1557. # [17:38] <fantasai> krit: we have some interpolation code, how you can interpolate between 3d matrices
1558. # [17:38] <fantasai> krit: But don't say how to interpolate between 2d and 2d matrices
1559. # [17:38] <fantasai> krit: So, I looked a bit at source code from FF and Webkit
1560. # [17:38] <fantasai> krit: FF has ... like 2d interpolation, modified to work on 2d
1561. # [17:38] <fantasai> krit: Webkit operates on 3d all the time
1562. # [17:39] <fantasai> krit: We have 4x4 matrix
1563. # [17:39] <fantasai> krit: we transform everything to 3d first, then take 2d values from the resulting matrix
1564. # [17:39] <fantasai> dbaron: I had testcases; possible it's been fixed but;
1565. # [17:39] <ChrisL> do you assume the three unused values are 0 0 1?
1566. # [17:39] <fantasai> dbaorn: If you do 2d transform in webkit between certain positions, it'll do something ike this [handwave] and then snap to that position
1567. # [17:40] <fantasai> dbaron: If you transition between matrices where sign of determinant is different
1568. # [17:40] <ChrisL> because they miight not be if you had scaling in there,
1569. # [17:40] <fantasai> dbaron: The matrix algorithm will produce interpolation that will spin you around x or y axis, and webkit will then throw out the 3d part of that
1570. # [17:40] <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant
1571. # [17:41] <fantasai> dbaron: Chrome seems to get these right now, but it didn't used to
1572. # [17:41] <smfr> chrome and safari do different things with the bottom row
1573. # [17:41] <fantasai> dbaron: That said, bottom row is looking ike it's doing something 3d to me
1574. # [17:41] <fantasai> dbaron: so I think Chromium is interpolating the bottom in 3d
1575. # [17:42] <fantasai> dbaron: Firefox is interpolating in 2d
1576. # [17:42] <smfr> in safari, middle row 2nd from right is weird
1577. # [17:42] * Joins: rotsuya_ (~rotsuya@public.cloak)
1578. # [17:43] <fantasai> [random discussion of these cases and what's happening in various browsers/versions]
1579. # [17:43] <fantasai> ChrisL: Promoting to 3d and then interpolating doesn't necessarily give you the wrong answer, just depends how you do it
1580. # [17:44] * Joins: nsakai (~nsakai@public.cloak)
1581. # [17:44] <fantasai> krit: Do we want to define an algorithm for this?
1582. # [17:44] <fantasai> krit: It seems to be hard in webkit atm
1583. # [17:44] <fantasai> dbaron: Seems we should say what happens, how you interpolate between these things
1584. # [17:45] <fantasai> krit: Are implementations willing to change?
1585. # [17:45] <fantasai> dean: FF must have extra code to handle this
1586. # [17:45] <fantasai> dbaron: We have separate paths for 2d vs 3d
1587. # [17:45] <fantasai> dean: What's 3d vs 2d?
1588. # [17:46] * Quits: mjs (~mjs@public.cloak) (mjs)
1589. # [17:46] * Quits: divya (~divya@public.irc.w3.org) (Ping timeout: 60 seconds)
1590. # [17:46] <fantasai> dbaron: The test for 2d is based on the components of the matrix
1591. # [17:47] <fantasai> dbaron: one other reason we want this code is... I don't think we support 3d transforms in all cases... though maybe we do
1592. # [17:48] <fantasai> [...]
1593. # [17:48] * Joins: Rossen (~Rossen@public.cloak)
1594. # [17:48] <fantasai> dean: It coudl be that the 3d interpolation is ok for enough cases
1595. # [17:48] <fantasai> dean: and we're just seing some bugs in webkit's implementation
1596. # [17:49] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 60 seconds)
1597. # [17:49] <fantasai> dean: would sitll like to know why chose to customize algorithm for 2d
1598. # [17:49] <fantasai> dbaron: he's in New Zealand...
1599. # [17:49] <fantasai> dean: I don't trust anyone from New Zealand
1600. # [17:49] <fantasai> dean: I accept the resolution
1601. # [17:49] <fantasai> krit: Even if we have interpolation in 3d space, still need to specify how get 2d components for e.g. getComputedStyle
1602. # [17:50] * Quits: stearns (~anonymous@public.cloak) (stearns)
1603. # [17:51] * Joins: SimonSapin (~simon@public.cloak)
1604. # [17:51] <fantasai> krit: It's the main thing left
1605. # [17:51] <fantasai> krit: I'd like to have just one algorithm in the spec, not multiple algorithms. 3d is already complex enough
1606. # [17:51] <fantasai> plinss: Anyone take an action to do research and get back?
1607. # [17:51] <fantasai> krit: What do you expect as the result?
1608. # [17:52] <fantasai> dbaron: Are we interoperable on 3d interpolation, in general?
1609. # [17:52] <smfr> sounds like we need some test cases!
1610. # [17:52] <fantasai> krit: Webkit is mostly following the algorithm in the spec
1611. # [17:52] <fantasai> dean: Made an effort to match the algorithm from you, although we may have bugs
1612. # [17:53] <fantasai> [more discussion of browser versions]
1613. # [17:53] <fantasai> krit: They look different. That might be a bug
1614. # [17:53] <fantasai> dbaron: Looking at our code, looks like we're still doing quaternian thing for both 2d and 3d, just do a different decomposition
1615. # [17:53] <fantasai> dean: Is the decomposition for speed or aesthetics?
1616. # [17:54] <fantasai> dbaron: Think it's for aesthetics
1617. # [17:54] <fantasai> dbaron: we use a decomposition that never generates a perspective
1618. # [17:54] <fantasai> dbaron: sometimes the 3d comp will generate a negative 1 perspective instead of 1
1619. # [17:54] <fantasai> dbaron: that's what leads to weird zoom-in-zoom-out behavior
1620. # [17:54] * Parts: glazou (~glazou@public.cloak) (glazou)
1621. # [17:54] <fantasai> ChrisL: That's not perspective, that's scale, right?
1622. # [17:55] * fantasai is so glad not working on this spec
1623. # [17:55] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
1624. # [17:55] * Joins: glazou (~glazou@public.cloak)
1625. # [17:55] * leaverou_away is now known as leaverou
1626. # [17:55] <fantasai> dbaron: Or maybe it's [this other] component that's affected
1627. # [17:55] <fantasai> ChrisL: Looks like it's the scale factor
1628. # [17:55] <fantasai> dean: I think if you get anything other than 1 in 4,4, you're done
1629. # [17:56] * Joins: SimonSapin (~simon@public.cloak)
1630. # [17:56] * Joins: rotsuya__ (~rotsuya@public.cloak)
1631. # [17:56] <fantasai> dbaron: It's something where you can take a 2d matrix, run 3d decomp, and get a -1 instead of a 1 in some parts
1632. # [17:56] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
1633. # [17:56] <fantasai> krit: Webkit always assumes 3d, even if given 2d
1634. # [17:56] * Quits: rotsuya_ (~rotsuya@public.cloak) (Ping timeout: 60 seconds)
1635. # [17:56] <fantasai> krit: You could use algorithm from 3d transforms and do some weird stuff like setting 1 for perspective
1636. # [17:56] <fantasai> krit: at the moment it's undefined
1637. # [17:57] <fantasai> Options are
1638. # [17:57] <fantasai> 1. Define 2d decompositing algorithm
1639. # [17:57] <fantasai> 2. Leave it undefined
1640. # [17:57] <fantasai> 3. Use 3d decomposing algorithm everywhere
1641. # [17:58] <fantasai> krit: Could also defer this issue to next level
1642. # [17:58] <fantasai> dean: Dunno. It is an interop issue.
1643. # [17:59] <fantasai> dean: If you query getComputedStyle halfway through a transition, would get different values on different browsers
1644. # [17:59] * Zakim dbaron, you asked to be reminded at this time to go home
1645. # [17:59] <fantasai> dbaron: Other thing is that algorithm could be tweaked so that the 3d algorithm will always work
1646. # [18:01] * Quits: nsakai (~nsakai@public.cloak) ("")
1647. # [18:01] <fantasai> dbaron: I'd like to at least email Matt Woodrow and Tim and ask them why we're doing what we're doing
1648. # [18:02] <fantasai> ACTION dbaron: investigate motivations for gecko approach to 2d matrix interpolation
1649. # [18:02] * RRSAgent records action 4
1650. # [18:02] * Quits: krit (~krit@public.cloak) ("Leaving.")
1651. # [18:02] <fantasai> Meeting closed.
1652. # [18:02] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
1653. # [18:03] * Quits: hiroki (hiroki@public.cloak)
1654. # [18:03] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
1655. # [18:03] * Quits: mishida (~mishida@public.irc.w3.org) ("Page closed")
1656. # [18:03] * Quits: kazutaka (~yamamoto_kazutaka@public.cloak) ("CHOCOA")
1657. # [18:03] * Quits: glazou (~glazou@public.cloak) (glazou)
1658. # [18:03] * Joins: dbaron (~dbaron@public.cloak)
1659. # [18:04] <TabAtkins_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1871
1660. # [18:04] * Quits: dino (~dino@public.cloak) (dino)
1661. # [18:04] <TabAtkins_> dbaron ^^^
1662. # [18:05] * mollydotcom wishes everyone a nice evening ~~~~
1663. # [18:05] * Quits: knobuta2 (~knobuta2@public.irc.w3.org) (Ping timeout: 60 seconds)
1664. # [18:05] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 60 seconds)
1665. # [18:06] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
1666. # [18:06] * Quits: mollydotcom (~mollydotcom@public.irc.w3.org) ("Page closed")
1667. # [18:06] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 60 seconds)
1668. # [18:07] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 60 seconds)
1669. # [18:07] * Quits: cox (~cox@public.irc.w3.org) (Ping timeout: 60 seconds)
1670. # [18:09] * Quits: sakkuru (~sakih@public.cloak) (Ping timeout: 60 seconds)
1671. # [18:09] * Joins: nsakai (~nsakai@public.cloak)
1672. # [18:10] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
1673. # [18:10] * Quits: r12a (rishida@public.cloak)
1674. # [18:10] * sylvaing is now known as sylvaing_away
1675. # [18:11] * Quits: nsakai (~nsakai@public.cloak) ("")
1676. # [18:11] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 60 seconds)
1677. # [18:14] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 60 seconds)
1678. # [18:16] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
1679. # [18:17] * sylvaing_away is now known as sylvaing
1680. # [18:20] * Quits: lmclister (~lmclister@public.irc.w3.org) (Ping timeout: 60 seconds)
1681. # [18:21] * Quits: rotsuya__ (~rotsuya@public.cloak) (Client closed connection)
1682. # [18:21] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
1683. # [18:24] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
1684. # [18:26] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 60 seconds)
1685. # [18:27] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
1686. # [18:31] * Joins: Rossen (~Rossen@public.cloak)
1687. # [18:34] * Quits: smfr (~smfr@public.cloak) (smfr)
1688. # [18:35] * Joins: glenn (~gadams@public.cloak)
1689. # [18:36] * Joins: antonp (~Thunderbird@public.cloak)
1690. # [18:40] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
1691. # [18:44] * Joins: smfr (~smfr@public.cloak)
1692. # [18:44] * Quits: smfr (~smfr@public.cloak) (smfr)
1693. # [18:51] * leaverou is now known as leaverou_away
1694. # [18:51] * Quits: darktears_ (~darktears@public.cloak) (Client closed connection)
1695. # [18:51] * Joins: darktears_ (~darktears@public.cloak)
1696. # [18:52] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
1697. # [18:55] * Joins: stearns (~anonymous@public.cloak)
1698. # [18:58] * Quits: drublic (~drublic@public.cloak) (Client closed connection)
1699. # [18:58] * Quits: stearns (~anonymous@public.cloak) (Client closed connection)
1700. # [18:58] * Joins: stearns (~anonymous@public.cloak)
1701. # [19:00] * Joins: Norbert (~standards@public.cloak)
1702. # [19:03] * Joins: trackbot (trackbot@public.cloak)
1703. # [19:08] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
1704. # [19:08] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
1705. # [19:13] * Joins: antonp (~Thunderbird@public.cloak)
1706. # [19:14] * Joins: Kid (~Kid@public.cloak)
1707. # [19:15] * Joins: antonp1 (~Thunderbird@public.cloak)
1708. # [19:16] * leaverou_away is now known as leaverou
1709. # [19:17] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
1710. # [19:17] * leaverou is now known as leaverou_away
1711. # [19:23] * Joins: drublic (~drublic@public.cloak)
1712. # [19:30] * sylvaing is now known as sylvaing_away
1713. # [19:32] * sylvaing_away is now known as sylvaing
1714. # [19:45] * Quits: Norbert (~standards@public.cloak) (Norbert)
1715. # [19:54] * sylvaing is now known as sylvaing_away
1716. # [20:30] * Joins: SimonSapin (~simon@public.cloak)
1717. # [20:41] * Joins: SamB_Mac_ (~SamB_MacG5@public.cloak)
1718. # [20:41] * Quits: SamB_MacG5 (~SamB_MacG5@public.cloak) (Client closed connection)
1719. # [20:42] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
1720. # [21:03] * sylvaing_away is now known as sylvaing
1721. # [21:15] * Joins: Norbert (~standards@public.cloak)
1722. # [21:30] * Joins: Ms2ger (~Ms2ger@public.cloak)
1723. # [21:44] * Joins: antonp (~Thunderbird@public.cloak)
1724. # [21:47] * Joins: tantek (~tantek@public.cloak)
1725. # [21:47] * Quits: antonp1 (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
1726. # [21:48] * Joins: glenn (~gadams@public.cloak)
1727. # [21:55] * Joins: r12a (rishida@public.cloak)
1728. # [22:01] * sylvaing is now known as sylvaing_away
1729. # [22:11] * Joins: krit (~krit@public.cloak)
1730. # [22:15] * Joins: cabanier (~cabanier@public.cloak)
1731. # [22:21] * sylvaing_away is now known as sylvaing
1732. # [22:22] * Joins: antonp1 (~Thunderbird@public.cloak)
1733. # [22:24] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
1734. # [22:30] * sylvaing is now known as sylvaing_away
1735. # [22:33] * Quits: drublic (~drublic@public.cloak) (Client closed connection)
1736. # [22:33] * Joins: drublic (~drublic@public.cloak)
1737. # [22:36] * Joins: rotsuya (~rotsuya@public.cloak)
1738. # [22:37] * Quits: drublic (~drublic@public.cloak) (Ping timeout: 60 seconds)
1739. # [22:38] * Joins: antonp (~Thunderbird@public.cloak)
1740. # [22:39] * Quits: antonp1 (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
1741. # [22:41] * Quits: r12a (rishida@public.cloak)
1742. # [22:41] * Joins: tomoyuki (~tshimizu3@public.cloak)
1743. # [22:48] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
1744. # [22:50] * Joins: rotsuya (~rotsuya@public.cloak)
1745. # [22:53] * Joins: antonp1 (~Thunderbird@public.cloak)
1746. # [22:55] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
1747. # [22:55] * Joins: dino (~dino@public.cloak)
1748. # [22:55] * Quits: Norbert (~standards@public.cloak) (Norbert)
1749. # [22:56] * Quits: krit (~krit@public.cloak) ("Leaving.")
1750. # [23:02] * Joins: liam (liam@public.cloak)
1751. # [23:04] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
1752. # [23:13] * Joins: hiroki (hiroki@public.cloak)
1753. # [23:22] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
1754. # [23:31] * Joins: glenn (~gadams@public.cloak)
1755. # [23:32] * Quits: hiroki (hiroki@public.cloak)
1756. # [23:32] * Joins: kensaku (~kensaku@public.cloak)
1757. # [23:33] * Quits: antonp1 (~Thunderbird@public.cloak) (antonp1)
1758. # [23:43] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
1759. # [23:45] * Quits: dino (~dino@public.cloak) (dino)
1760. # Session Close: Tue Oct 30 00:00:00 2012

The end :)