/irc-logs / w3c / #css / 2012-02-06 / end

Options:

1. # Session Start: Mon Feb 06 00:00:00 2012
2. # Session Ident: #css
3. # [00:34] * Joins: nimbu (Adium@24.18.47.160)
4. # [06:09] * sylvaing_away is now known as sylvaing
5. # [06:18] * Quits: nimbu (Adium@24.18.47.160) (Quit: Leaving.)
6. # [06:39] * Joins: Rossen (Rossen@82.66.216.139)
7. # [06:40] * sylvaing is now known as sylvaing_away
8. # [06:57] * Quits: Rossen (Rossen@82.66.216.139) (Ping timeout)
9. # [07:53] * Quits: cyril (chatzilla@203.12.172.254) (Connection reset by peer)
10. # [07:53] * Joins: tantek (tantek@92.151.219.3)
11. # [07:54] * Quits: tantek (tantek@92.151.219.3) (Connection reset by peer)
12. # [07:54] * Joins: tantek (tantek@92.151.219.3)
13. # [08:44] * Quits: tantek (tantek@92.151.219.3) (Quit: tantek)
14. # [09:14] * Joins: arron (Arron@24.17.123.244)
15. # [09:24] * Quits: florianr (florianr@213.236.208.22) (Quit: Leaving.)
16. # [09:31] * Joins: alexmog_ (qw3birc@128.30.52.28)
17. # [09:31] * Joins: dbaron (dbaron@128.93.135.77)
18. # [09:32] * Joins: sylvaing (sylvaing@128.93.135.76)
19. # [09:32] * Joins: smfr (smfr@128.93.135.37)
20. # [09:32] * Joins: jdaggett (jdaggett@128.93.134.208)
21. # [09:32] * Joins: florian (florianr@128.93.135.13)
22. # [09:32] <jdaggett> hello
23. # [09:32] <florian> hello
24. # [09:32] <jdaggett> oh lovely!!
25. # [09:32] <sylvaing> omg
26. # [09:33] * Joins: kojiishi (kojiishi@128.93.135.158)
27. # [09:33] <jdaggett> what is port 21 anyways...?
28. # [09:33] <dbaron> port 21 is ftp
29. # [09:37] * Quits: vhardy (vhardy@173.230.149.95) (Client exited)
30. # [09:37] * Quits: alexmog (alexmog@173.230.149.95) (Client exited)
31. # [09:37] * Quits: plinss (plinss@173.230.149.95) (Client exited)
32. # [09:37] * Quits: sylvaing_away (sylvaing@173.230.149.95) (Client exited)
33. # [09:37] * Quits: shans_away (shans@173.230.149.95) (Client exited)
34. # [09:38] * Joins: alexmog_away (alexmog@173.230.149.95)
35. # [09:38] <jdaggett> welcome back
36. # [09:38] * alexmog_away is now known as alexmog
37. # [09:38] * Joins: TabAtkins_ (tabatkins@74.125.122.49)
38. # [09:38] * Joins: plinss_away (plinss@173.230.149.95)
39. # [09:38] * Joins: antonp (805d86d1@78.129.202.38)
40. # [09:39] * Joins: glazou (glazou@128.93.135.193)
41. # [09:39] * plinss_away is now known as plinss
42. # [09:39] * Joins: plinss_ (plinss@128.93.135.60)
43. # [09:39] <glazou> test
44. # [09:39] * Joins: shans_away (shans@173.230.149.95)
45. # [09:39] <TabAtkins_> pong
46. # [09:39] * shans_away is now known as shans
47. # [09:39] <dbaron> ooh, we're discussing tests? :-P
48. # [09:39] * Joins: sylvaing_away (sylvaing@173.230.149.95)
49. # [09:40] <dbaron> ScribeNick: dbaron
50. # [09:40] <dbaron> Topic: Agenda
51. # [09:40] * Joins: vhardy_away (vhardy@173.230.149.95)
52. # [09:40] <dbaron> Daniel: How much time for regions?
53. # [09:40] <dbaron> Vincent: 2+ hours would be good
54. # [09:40] * vhardy_away is now known as vhardy
55. # [09:40] * Joins: tantek (tantek@128.93.135.20)
56. # [09:40] <dbaron> Daniel: I suggest we break around 12:00 or 12:30 to avoid crowds.
57. # [09:41] <dbaron> Daniel: means we have roughly 2.5 hours for this morning
58. # [09:41] <tantek> good morning
59. # [09:41] <dbaron> Daniel: Maybe start with review of documents that want to publish LC, CR, etc.
60. # [09:41] <dbaron> Elika: Most of those have issues.
61. # [09:41] * Joins: Rossen (Rossen@128.93.134.228)
62. # [09:41] <dbaron> jdaggett: There's some coalescing of the agenda that could be done (by modules).
63. # [09:41] <dbaron> jdaggett: Maybe talk about logistics, San Diego meeting, etc.
64. # [09:42] <dbaron> Topic: Next meetings
65. # [09:42] <dbaron> Vincent: So for Hamburg, I sent an email. There's an event in Hamburg at the time of the meeting: the port anniversary.
66. # [09:42] <dbaron> Vincent: The city apparently gets pretty busy. It starts on Friday, the last day of the F2F.
67. # [09:43] <dbaron> Vincent: Originally when I talked to people in Hamburg they said it wasn't a problem; now they said we need to make reservations.
68. # [09:43] <dbaron> Vincent: We've blocked rooms in some hotels; people should make reservations.
69. # [09:43] <dbaron> Vincent: We need to renew the hotel room block week by week.
70. # [09:45] <dbaron> (discussion of trains)
71. # [09:46] * Joins: drublic (drublic@88.74.75.215)
72. # [09:47] <dbaron> Daniel: So we stay firm on Hamburg? OK for everyone? Book soon.
73. # [09:47] <dbaron> jdaggett: Håkon offered to host in Oslo, too. Should we consider that?
74. # [09:48] <dbaron> ?: coord with SVG
75. # [09:48] <dbaron> Daniel: ok, let's keep Hamburg
76. # [09:49] <dbaron> Vincent: The Adobe rates for hotels should be better than the ones on the meeting page.
77. # [09:49] <dbaron> Vincent: Just the worry that other hotels will fill up.
78. # [09:50] <dbaron> Topic: August meeting
79. # [09:50] <dbaron> jdaggett: Wiki now says week of 13-17
80. # [09:50] <dbaron> jdaggett: We didn't lock down which dates
81. # [09:51] <dbaron> peterl: I can host at HP or somewhere downtown. (?)
82. # [09:51] <dbaron> SteveZ: middle 3 have least impact on weekend
83. # [09:51] <dbaron> Håkon: I'd prefer close to weekend.
84. # [09:51] <dbaron> jdaggett: Prefer 13-15
85. # [09:52] <dbaron> Daniel: Better to stay over a saturday night for plane fares.
86. # [09:52] <dbaron> Daniel: Probably having weekend before the meeting best.
87. # [09:52] <dbaron> Florian: Earlier the better for me... week ...
88. # [09:53] <dbaron> Håkon: Ideally the next week for me.
89. # [09:53] <dbaron> SteveZ: next week fine for me too
90. # [09:53] * Quits: plinss_ (plinss@128.93.135.60) (Quit: plinss_)
91. # [09:53] <dbaron> Daniel: The week after (20-22) could be better for airlines if you fly Europe to US because it's theend of the holidays...
92. # [09:54] * Joins: plinss_ (plinss@128.93.135.60)
93. # [09:54] <dbaron> jdaggett: Week after would be tricky for me.
94. # [09:54] <dbaron> RESOLVED: San Diego meeting, August 13-15
95. # [09:54] <dbaron> hosted by HP
96. # [09:54] <dbaron> Topic: TPAC, Lyon
97. # [09:57] <dbaron> Topic: www-style
98. # [09:57] <dbaron> Daniel: There was a thread on www-style to split the mailing list to multiple lists. I strongly object.
99. # [09:57] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
100. # [09:58] <dbaron> Daniel: It would double or triple the work the co-chairmen have to review items for agendas.
101. # [09:58] <dbaron> Daniel: The new mailing list will double or triple the threads and new people will never know where to post something.
102. # [09:58] <dbaron> jdaggett: Could an advocate for splitting the list explain their position?
103. # [09:59] <dbaron> Elika: I'm worried about the level of traffic.
104. # [09:59] <dbaron> Tantek: I agree with what Daniel said. I'd go further and say w3c has too many mailing lists.
105. # [09:59] <dbaron> Tantek: If anything, we should be looking at collapsing.
106. # [09:59] <dbaron> Tantek: I see no reason for fx list to exist; it should be rolled into www-style ASAP.
107. # [10:00] <dbaron> Tantek: I think forking of mailing lists and then growing to be too big has been happening the entire time I've been at W3C.
108. # [10:00] <dbaron> Sylvain: Is the number of lists a problem?
109. # [10:00] <dbaron> Tantek: Yes, because of the effect Daniel speaks about.
110. # [10:00] <dbaron> Florian: Each single list grows to be the maximum amount one person can read.
111. # [10:00] <dbaron> Tantek: Splitting lists doesn't lead to less traffic.
112. # [10:01] <dbaron> SteveZ: It's difficult to split because topics last for some period of time and then tends to die out.
113. # [10:01] * Quits: tantek (tantek@128.93.135.20) (Ping timeout)
114. # [10:02] * Joins: macpherson (macpherson@74.125.56.17)
115. # [10:02] <dbaron> Bert: Agree there's too much traffic. Nearest after this is WebApps. www-style is 40% more than WebApps and double the next.
116. # [10:02] * sylvaing a css-bikeshed list could be of use...
117. # [10:02] <dbaron> Florian: Yes, there's a lot of traffic; but splitting won't help.
118. # [10:03] <dbaron> Daniel: We invited the public -- this is part of the bad side of that. Second, we could probably stop better a few useless threads.
119. # [10:03] <dbaron> Daniel: Peter and I cannot monitor everything.
120. # [10:03] <dbaron> Daniel: If you ping us during the week to ask us to please step in and stop it, we can do that.
121. # [10:04] <dbaron> Daniel: That's happened a few times, and we can try doing it more.
122. # [10:04] <dbaron> Tantek: That's good -- it puts the responsibility on all of us to help reduce useless threads.
123. # [10:05] <dbaron> Florian: There are some where it's easy to say it should be stopped, and some not.
124. # [10:05] <dbaron> Simon: And people need to fix the subject line when the topic of the thread changes.
125. # [10:05] <dbaron> Tantek: Do we have a www-style FAQ for new people on the list?
126. # [10:05] <dbaron> Daniel: We tried that back in 1997 or beginning of 1998; it was painful to send the FAQ every 2 weeks or month.
127. # [10:06] <dbaron> Tantek: I think we could try again.
128. # [10:06] <dbaron> Elika: Let's (Tantek & I) try to write an FAQ and connect it to the archive page and send it out once and see if it helps.
129. # [10:06] <dbaron> Bert: It's technically possible to send when someone subscribes.
130. # [10:07] <dbaron> Tantek: Sending to the list is better because everyone knows everyone else has received it.
131. # [10:07] <dbaron> Daniel: Can we get rid of people as a last resort?
132. # [10:07] <dbaron> Bert: We can unsubscribe somebody from a list or we can ban somebody from all mailing lists.
133. # [10:08] <dbaron> Anton: I think the signal to noise ratio is still pretty good.
134. # [10:08] <dbaron> Anton: And people need to put [spec] at the start -- we can filter on that.
135. # [10:08] <dbaron> Tantek: That could be material for the FAQ.
136. # [10:09] <dbaron> (fast discussion between Tantek and Elika about retitling threads, authority to tell people to stop or to change the topic)
137. # [10:09] <dbaron> Tantek: Issue is 2 people quickly replying back to each other.
138. # [10:10] <dbaron> Elika: Tantek & I will write up something and then post it once or twice, not regularly.
139. # [10:10] <dbaron> ACTION fantasai with Tantek to write a FAQ for www-style
140. # [10:10] * trackbot noticed an ACTION. Trying to create it.
141. # [10:10] <trackbot> Created ACTION-418 - With Tantek to write a FAQ for www-style [on Elika Etemad - due 2012-02-13].
142. # [10:11] <dbaron> Daniel: Don't send to www-style immediately so WG can review it first.
143. # [10:11] <dbaron> Topic: meeting wifi
144. # [10:11] <dbaron> (not minuted)
145. # [10:13] <dbaron> Topic: W3C Mercurial for Dummies status
146. # [10:13] <dbaron> dbaron: I wrote some parts, I think others wrote more parts
147. # [10:14] <dbaron> jdaggett: Have we made a decision to go to Mercurial?
148. # [10:14] <dbaron> Tantek: No, this is one of the dependencies.
149. # [10:14] <dbaron> jdaggett: I think one of the key items is getting history from CVS to Mercurial.
150. # [10:14] * Joins: astearns (qw3birc@128.30.52.28)
151. # [10:14] <dbaron> Elika: We'd do that, but first we'd need to decide to switch to it.
152. # [10:14] <dbaron> dbaron: It is possible.
153. # [10:14] <dbaron> Håkon: It's a lot of work to make the switch; what's the benefit?
154. # [10:15] <dbaron> Håkon: It's small projects.
155. # [10:15] <smfr> cvs -> mercurial: http://mercurial.selenic.com/wiki/RepositoryConversion
156. # [10:15] * Quits: TabAtkins_ (tabatkins@74.125.122.49) (Ping timeout)
157. # [10:16] <dbaron> Tantek: I tried to look at the document and ran into numerous problems in the installing mercurial step -- added problems to the wiki page.
158. # [10:16] <dbaron> Tantek: The quality of document is not up to par with the CVS document.
159. # [10:16] <dbaron> q+
160. # [10:17] <smfr> http://wiki.csswg.org/spec/hg
161. # [10:17] <fantasai> dbaron: I don't know if anyone agged the document was complete yet
162. # [10:17] <fantasai> dbaron: I'll also note the CVS doc contains all the problems you run into because you ran into them and put them there.
163. # [10:17] <fantasai> dbaron: You can't build up that kind of documentation without that experience.
164. # [10:17] <fantasai> dbaron: Peter wrote the Installing for Macs section
165. # [10:18] <fantasai> questions of what problem is being solved
166. # [10:19] <fantasai> fantasai: We're starting to fork specs a lot, and CVS doesn' let us do that with history
167. # [10:19] <fantasai> dbaron: are we planning one repo per spec or one repo for all specs?
168. # [10:19] <fantasai> tantek: I think that's a separate topic
169. # [10:19] <fantasai> dbaron: The setup is doable. Question of whether to use it is important
170. # [10:20] <fantasai> tantek: I don't want to switch to a system where people don't document their problems.
171. # [10:20] <fantasai> dbaron: Mercurial is a one-line install on Linux
172. # [10:22] <fantasai> tantek: We shouldn't be discussing cvs vs mercurial, we should switch to git
173. # [10:22] <fantasai> fantasai: Doesn't make sense to switch to git when our test suite is in Mercurial.
174. # [10:23] <fantasai> plinss: Hg vs. Git, I don't see a significant advantage of git over Hg, and the rest of W3C uses Hg. I don't think there's a benefit for us to be different.
175. # [10:23] <fantasai> jdaggett: Ok, seems to me there's enough other variables for moving to Mercurial, and we just need to get it set up.
176. # [10:24] <fantasai> jdaggett: I thin what Rossen said is key: having a simple setup on Windows
177. # [10:24] <fantasai> glazou: If you want to make it easy on Windows, you just get the Mozilla build tools, and it's one click.
178. # [10:24] <fantasai> dbaron: The Hg installer on Windows is just as easy
179. # [10:24] * Joins: vincent_ (qw3birc@128.30.52.28)
180. # [10:25] <fantasai> jdaggett: There's a secondary issue, which is, a lot of our specs are still using Bert's tools.
181. # [10:25] <fantasai> jdaggett: It's not set up to run locally, which to me is a problem.
182. # [10:25] <fantasai> jdaggett: I see comments, I have to get Bert to add a biblio entry
183. # [10:25] <fantasai> Bert: you can add that yourself
184. # [10:26] <fantasai> Bert: I put it as a CGI script so people don't have to install things locally, but we can do that
185. # [10:26] <fantasai> jdaggett: I think one of the things we have to do is move some of that infrastructure to whatever we're switching to
186. # [10:26] <fantasai> jdaggett: So that I just have a Makefile that will make in my directory
187. # [10:27] <fantasai> jdaggett: The problem is the bibliography is still in the old CVS database
188. # [10:27] <fantasai> Bert: hmm, that could be tricky..
189. # [10:28] <fantasai> jdaggett: Should make it easy for people to do it locally, and then for you, you have an extra step to get it updated on the server
190. # [10:29] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
191. # [10:29] <fantasai> jdaggett: There are details in the script that need updating. E.g. script doesn't know how to generate descriptor tables for @rules
192. # [10:30] <fantasai> Bert: yeah, sure, I can do something about descriptors
193. # [10:30] <fantasai> jdaggett: If the build script is in the same system as the specs and can run locally, then other people can also help improve the build scripts
194. # [10:30] <fantasai> smfr: How much work is it to enable Make to run offline?
195. # [10:30] <fantasai> dbaron: I had it working a few years ago, but then upgraded and doesn't work anymore
196. # [10:31] <fantasai> jdaggett: Uses tools
197. # [10:31] <fantasai> smfr: Would like to be able to just check out Hg repo and be able to run Make
198. # [10:31] <fantasai> Bert: Might be easy on linux/Mac, unsure about Windows
199. # [10:31] <fantasai> dbaron: Didn't somebody reimplement Bert's script?
200. # [10:32] * Joins: tantek (tantek@128.93.135.20)
201. # [10:32] <fantasai> smfr: can't effectively work offline if we can't build offline
202. # [10:33] * Joins: jet (junglecode@128.93.134.212)
203. # [10:34] <fantasai> smfr: i don't think we should block on the document
204. # [10:34] <fantasai> glazou: That was what we decided
205. # [10:34] <fantasai> tantek: plan was to work on the document, nothing happened
206. # [10:34] * Joins: alexmog_ (qw3birc@128.30.52.28)
207. # [10:35] <fantasai> fantasai: document was edited. Just nobody ran into your problems, so those problems weren't documented.
208. # [10:35] <fantasai> Tantek: Nobody ran into problems?
209. # [10:35] <fantasai> Nope.
210. # [10:35] <fantasai> plinss: Might help to link directly to Mercurial installer instead of MacPorts
211. # [10:36] <fantasai> jdaggett: I think we've resolved that we will switch to Mercurial, and we will work through the problems people have.
212. # [10:36] <fantasai> Tantek: What about working offline?
213. # [10:36] <fantasai> jdaggett: It's a separate issue.
214. # [10:37] <fantasai> plinss: I think we can set the direction
215. # [10:37] <fantasai> jdaggett: The issue I brought up, even if we don't go to Hg, still exists
216. # [10:38] <fantasai> glazou: The proposal is to move to Hg and fix the documents later
217. # [10:39] <fantasai> RESOLVED: Move to Mercurial, work on docs.
218. # [10:39] <dbaron> fantasai: I think we need to work on some details about the move.
219. # [10:40] <dbaron> fantasai: (inaudible) pull and rebase (inaudible)
220. # [10:41] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
221. # [10:41] <fantasai> plinss: I don't want to have 3-4 different Hg docs on our wiki.
222. # [10:41] <fantasai> plinss: Not have separate docs for specs and testing
223. # [10:41] <fantasai> glazou: Break now. Vendor prefixes later.
224. # [10:41] * Joins: alexmog_ (qw3birc@128.30.52.28)
225. # [10:54] * Quits: alexmog (alexmog@173.230.149.95) (Client exited)
226. # [10:54] * Quits: vhardy (vhardy@173.230.149.95) (Client exited)
227. # [10:54] * Quits: sylvaing_away (sylvaing@173.230.149.95) (Client exited)
228. # [10:54] * Quits: shans (shans@173.230.149.95) (Client exited)
229. # [10:54] * Quits: plinss (plinss@173.230.149.95) (Client exited)
230. # [10:54] * plinss_ is now known as plinss
231. # [10:54] * plinss is now known as plinss_
232. # [10:55] * Joins: plinss_away (plinss@173.230.149.95)
233. # [10:55] * Joins: kojiishi (kojiishi@128.93.135.158)
234. # [10:55] * Joins: alexmog_away (alexmog@173.230.149.95)
235. # [10:55] * alexmog_away is now known as alexmog
236. # [10:55] * plinss_away is now known as plinss
237. # [10:56] * Joins: shans_away (shans@173.230.149.95)
238. # [10:56] * shans_away is now known as shans
239. # [10:56] * Joins: sylvaing_away (sylvaing@173.230.149.95)
240. # [10:56] * Joins: vhardy_away (vhardy@173.230.149.95)
241. # [10:57] * vhardy_away is now known as vhardy
242. # [10:57] <fantasai> Scribe: fantasai
243. # [10:57] <fantasai> Topic: Vendor Prefixes
244. # [10:58] <fantasai> glazou: Title is: Why and How to Implement Other Vendors' Prefixes
245. # [10:58] <fantasai> tantek: This is a specific subtopic of vendor prefixes
246. # [10:58] <fantasai> tantek: The problem statement rightnow, and this is a problem for Mozilla and any other non-WebKit browser
247. # [10:58] * Quits: jet (junglecode@128.93.134.212) (Quit: jet)
248. # [10:58] <fantasai> tantek: Sites have webkit-specific content, and serve backup content to everyone else. Specifically for mobile content.
249. # [10:59] <fantasai> tantek: Non-WebKit browsers face prisoners dilemma
250. # [10:59] <fantasai> tantek: similar to quirks in 2003 or so
251. # [10:59] <fantasai> tantek: At this point we're trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla
252. # [10:59] <fantasai> plinss: Zero.
253. # [10:59] <fantasai> tantek: Currently we have zero. Zero is no longer an option for us.
254. # [10:59] <dbaron> Florian, Sylvain: Zero is not an option for us anymore either.
255. # [10:59] <fantasai> Florian: Opera is in the same situation.
256. # [11:00] <fantasai> tantek: We're doing an analysis of what properties we need to consider. I want to minimize this.
257. # [11:00] <fantasai> glazou: A long time ago, Mozilla had an Evangelism team that would call up the website owners and ask them to change.
258. # [11:00] <fantasai> Florian: Opera has a large and active one, but it does not scale.
259. # [11:00] * Joins: jet (jet@128.93.134.212)
260. # [11:01] <fantasai> Florian: I found on the rough anlasys of top 1000 websites, several percent use webkit prefixes without a fallback for others.
261. # [11:01] <fantasai> Florian: Regardless of how we ended up here, if we don't support webkit prefixes, we are locking ourselves out of parts of the mobile web.
262. # [11:02] <fantasai> sylvaing: -webkit-text-size-adjust was implemented in IE. So we pulled it out and asked that it be submitted for standardization. But it wasn't.
263. # [11:02] <fantasai> tantek: We don't consider this a long-term situation. The goal is to open up the webkit-specific part of the web to others, same as implementing parts of IE-specific web.
264. # [11:02] <fantasai> tantek: We do have some experience in not screwing this up.
265. # [11:02] <fantasai> tantek: But it has come time to discuss this publicly. I have put our data and findings on public wiki pages.
266. # [11:03] <fantasai> tantek: I'm bringing to this group b/c affects more than just Mozilla.
267. # [11:03] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
268. # [11:03] <fantasai> tantek: If we come up with a solution together, we can hopefully minimize the solution.
269. # [11:03] * Joins: Ms2ger (Ms2ger@94.226.67.71)
270. # [11:03] <fantasai> plinss: You said this is a short-terms olution. Quirks mode was supposed to be a quirks-mode solution.
271. # [11:03] <fantasai> tantek: No it wasn't.
272. # [11:03] <fantasai> plinss: Yes it was. I implemented it before you did.
273. # [11:04] <fantasai> plinss: The intention was to solve a short-term problem. It was supposed to be gone in a few years. We're stuck with it.
274. # [11:04] <fantasai> plinss: If we open this Pandora's box, we're going to be stuck with it.
275. # [11:04] <fantasai> plinss: If people implement other vendor prefixes, then everyone will implement others prefixes and we'll be stuck with it forever.
276. # [11:05] <fantasai> Florian: We are currently losing market share because of not implementing -webkit- properties.
277. # [11:05] <fantasai> glazou: Do you have a -o- version?
278. # [11:05] <fantasai> glazou: I can write an add-on that converts the style sheet.
279. # [11:05] <fantasai> dbaron: What's the difference between that and implementing it in the engine?
280. # [11:07] <fantasai> Tab: Given the discussion is about webkit being a monoculture on Mobile, if webkit decides to remove a prefix then it's okay for everyone to remove prefixes also.
281. # [11:07] <fantasai> Florian: Some prefixes will not be dropped by webkit
282. # [11:07] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
283. # [11:07] <fantasai> glazou: None will be dropped.
284. # [11:07] <fantasai> tantek: So this is not saying implement -webkit- across the board.
285. # [11:08] <fantasai> tantek: This is consider implementing some -webkit- properties, and be very deliberate about which ones and why.
286. # [11:08] <fantasai> tantek: We need to do analysis about how many sites we can fix and how much.
287. # [11:08] <fantasai> tantek: I don't see authors being recommended to use webkit, b/c works mozilla as well. Goal is to get some sites working on Mozilla.
288. # [11:09] <fantasai> tantek: When I was implementing Quirks mode in MacIE. I didn't think it would be short-term at all.
289. # [11:09] * Joins: alexmog_ (qw3birc@128.30.52.28)
290. # [11:09] <fantasai> tantek: There were ~90 places where used switched.
291. # [11:09] <fantasai> tantek: Over time, I was able to cut some.
292. # [11:09] <fantasai> tantek: By the time Tasman got parked got to ~80
293. # [11:09] <fantasai> tantek: Probably never go to zero, due to box-sizing, etc.
294. # [11:10] <fantasai> tantek: but some of those problems *were* short term.
295. # [11:10] <fantasai> tantek: wanted to offer that as a data point.
296. # [11:10] <fantasai> Alan: When you do analysis of site using webkit prefixes, do you go back and see whether implementing the prefix will fix that 10%?
297. # [11:11] <fantasai> Alan: Or are there other complications where they're doing browser-sniffing or otherwise wouldn't work even if you implement these prefixes?
298. # [11:11] <fantasai> Alan: I'm wondering about the efficacy of implementing webkit prefixes
299. # [11:11] <fantasai> tantek: None. We will also need to send a webkit-tricking UA string.
300. # [11:12] <fantasai> tantek: Just like WebKit sent "like Gecko" in its UA string, we have to do the same thing again
301. # [11:12] <fantasai> glazou: Two implementations wwill not fully match, but you will treat -o- and -webkit- as the same.
302. # [11:12] * Quits: plinss_ (plinss@128.93.135.60) (Quit: plinss_)
303. # [11:12] <fantasai> Florian, Sylvain: Evangelism has failed.
304. # [11:13] <fantasai> glazou: Have you tried pinging the WASP about that? Other activitists of web standards?
305. # [11:13] <fantasai> sylvaing: If MS can't scale to handle this, you think WASP can?
306. # [11:13] <fantasai> tantek: Opposite is happening right now. Web standards activists are teaching people to use -webkit-
307. # [11:13] <fantasai> tantek: People like Lea Verou.
308. # [11:14] <fantasai> tantek: Their demos are filled with -webkit-. You will see presentations from all the web standards advocates advocating people to use -webkit- prefixes.
309. # [11:14] <fantasai> glazou: Tab, how do you feel about that? Is there anything you can do?
310. # [11:14] <fantasai> Tab: There's enough legacy content that there are some properties that we can't drop the prefixes.
311. # [11:14] <fantasai> Tab: Given that's a reality for us, totally sympathetic that it's a problem for everyone else.
312. # [11:15] <fantasai> Tab: These are used on production sites.
313. # [11:15] <fantasai> smfr: Two categories of problem.
314. # [11:15] <fantasai> smfr: We have things like Transforms, which are being standardized and implemented by other browsers.
315. # [11:15] <fantasai> smfr: There's others like text-size-adjust, which is only propertietary on iPhone
316. # [11:16] <fantasai> smfr: Not sure about standardizing things like that.
317. # [11:16] <fantasai> smfr: Some of this is due to iPhone's success
318. # [11:16] <fantasai> ...
319. # [11:16] <fantasai> Florian: If something is intended for internal use, then it is proprietary.
320. # [11:17] <fantasai> Florian: But once it's encouraged out on the Open Web, it cannot be proprietary anymore.
321. # [11:17] <fantasai> Florian: The cat is out of the box.
322. # [11:17] <fantasai> Florian: ... If you submit a spec aobut htings like this, we're back into the other case.
323. # [11:17] <fantasai> Florian: ...
324. # [11:17] <fantasai> Florian: If we don't get specs for these, the problem is harder. But I think we should get specs for these.
325. # [11:17] * Joins: kojiishi (kojiishi@128.93.135.158)
326. # [11:18] <fantasai> tantek: Once it gets served over the open Web, it is no longer proprietary.
327. # [11:18] <fantasai> sylvaing: A lot of authors assume that any -webkit- property is in the standards process.
328. # [11:18] <fantasai> ..
329. # [11:19] <fantasai> jdaggett: Maybe use a different prefix?
330. # [11:19] <fantasai> tantek: Once it's on the open Web, it's not proprietary
331. # [11:19] <fantasai> jdaggett: -apple-, or -iphone-
332. # [11:19] <fantasai> alexmog_: Once Apple ships -webkit-, it's frozen.
333. # [11:19] <tantek> it can be considered experimental, but claiming it is proprietary-only is inaccurate
334. # [11:20] <fantasai> smfr: It's not necessarily frozen, might be changed.
335. # [11:20] <fantasai> alexmog_: We will never drop -ms-, or change -ms- behavior.
336. # [11:20] <fantasai> ...
337. # [11:20] <fantasai> Florian: It doesn't solve the problem.
338. # [11:20] <fantasai> Florian: Whether it's -webkit-border-radius or -draft25-border-radius,
339. # [11:20] <fantasai> Florain: You will get content depending on that.
340. # [11:21] <fantasai> alexmog_: Doesn't change the problem, but you can think about it differently.
341. # [11:21] <fantasai> tantek: I have a couple of questions.
342. # [11:21] <fantasai> tantek: Bringing to WG because I believe we can solve problem better together than individually.
343. # [11:21] <fantasai> tantek: I'm going with assumption that none of us want to just implement all -webkit- properties.
344. # [11:22] <fantasai> Tab: I don't even want to implement all -webkit- properties.
345. # [11:22] <tantek> https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#questions_and_methodology
346. # [11:22] <fantasai> tantek: What are the thresholds, even approximate, for implementing -webkit- properites (or none)?
347. # [11:22] <fantasai> glazou: Unbelieveable we are having this discussion.
348. # [11:23] <fantasai> Florian: Our job is to solve interoperability. We want to discuss it here, because that's our job.
349. # [11:23] <fantasai> tantek: Help us minimize the damage.
350. # [11:23] <fantasai> dbaron: Part of what Tantek is saying is that we want to look very carefully at the evidence to see whether we need to do this.
351. # [11:23] <fantasai> dbaron: Can we get the draft to a point where we can unprefix?
352. # [11:24] <fantasai> dbaron: E.g. 2D transforms, based on Aryeh's tests, are interoperable enough to drop prefixes right now.
353. # [11:24] <fantasai> dbaron: Maybe revisit our decision to merge 2D and 3D transforms, and take draft to CR in a couple months.
354. # [11:24] <fantasai> Florian: Might not be enough to solve the problem.
355. # [11:24] <fantasai> dbaron: What Tantek is saying is that we're not going to look at this as a single problem.
356. # [11:25] <fantasai> dbaron: The more we can unprefix, perhaps the less we have this problem.
357. # [11:25] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
358. # [11:25] <fantasai> tantek: One possible proposal is to only parse other vendors' prefixes in conjunction with parsing unprefixed.
359. # [11:25] <fantasai> tantek: e.g. with -webkit-transform. We wouldn't parse that until we also parse transform.
360. # [11:26] <fantasai> tantek: Thereby giving authors option to just use unprefixed, hopefully biasing new authors to using that instead.
361. # [11:26] <fantasai> tantek: That is one example of methodology that we want to apply to limit the damage of this.
362. # [11:26] <fantasai> tantek: If you can think of other examples of ways of thinking about this, to provide ways of moving forward.
363. # [11:26] <fantasai> tantek: We are absolutely open to other ideas.
364. # [11:27] <fantasai> glazou: Simon said that Apple WebKit implemented -webkit-text-size adjust for better experience on mobile.
365. # [11:27] <fantasai> glazou: I suppose this aims at mobile.
366. # [11:27] <fantasai> tantek, florian: yes.
367. # [11:28] <fantasai> glazou: This is replacing standardization by turning one implementation into a de facto standard.
368. # [11:28] <fantasai> glazou: Instead of creating a de jure standard here.
369. # [11:28] <fantasai> glazou: The right thing to do would be for Apple to submit text-size-adjust for standardization here.
370. # [11:28] <fantasai> dbaron: I don't see why Apple has to write the spec if they're not writing the spec.
371. # [11:29] <fantasai> dbaron: We dealt with this with IE6. Bunch of stuff we had to copy IE6 into the spec and implement that.
372. # [11:29] <fantasai> Tab: IE6 monoculture of desktop. WebKit monoculture of mobile. It's the same problem.
373. # [11:30] <fantasai> smfr: I can take a list of properties we need back and see if we can bring it back for standardization
374. # [11:30] <fantasai> glazou: In a reasonable timeframe?
375. # [11:30] <fantasai> smfr: Yes.
376. # [11:30] <fantasai> dbaron: Off the top of my head, the only thing not in this WG that's a major issue is text-size-adjust
377. # [11:31] <fantasai> Florian: -webkit-appearance
378. # [11:31] <fantasai> ?: That's in UI. But was dropped
379. # [11:31] <fantasai> fantasai: Maybe we need appearance: auto | none. (None of the other values are useful.)
380. # [11:31] <tantek> https://bugzilla.mozilla.org/show_bug.cgi?id=708406
381. # [11:32] <fantasai> tantek: Have to do crawls by switching UA strings. But here's our data.
382. # [11:32] <fantasai> sylvaing: The -webkit-tap-highlight-color is very highly requested
383. # [11:33] <fantasai> fantasai: I think that's a case that's not very critical. Nice to have, but not having it won't break anything. We should solve the problem it's solving, but don't think we need to implement exactly that.
384. # [11:35] <fantasai> ...
385. # [11:35] <fantasai> tantek: I think if you're working on open standards, you should propose your features before you implement them and discuss that here.
386. # [11:35] <fantasai> smfr: We can't do that.
387. # [11:35] <fantasai> sylvaing: We can't do that either.
388. # [11:36] <fantasai> tantek: We're going to push you to do that sooner and sooner.
389. # [11:36] <fantasai> jdaggett: If you're proposing something that's going to be put on a Web page, how is that proprietary?
390. # [11:36] <fantasai> Alan: Do you agree with fantasai that tap-highlight-color isn't needed?
391. # [11:36] <fantasai> Alan: Not asking about threshold. fantasai saying that it's not necessary functionality.
392. # [11:36] <fantasai> dbaron: I agree.
393. # [11:37] <fantasai> dbaron: Like Tantek said, i think we should look at each item carefully.
394. # [11:37] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
395. # [11:37] <fantasai> dbaron: The problem we're trying to solve is that users don't want to use a browser because it doesn't support certain functionality.
396. # [11:37] <fantasai> dbaron: Users don't really care about tap-highlight-color.
397. # [11:38] <dbaron> dbaron: Users care about whether they can read the web page and can get to its functionality.
398. # [11:38] * Quits: Ms2ger (Ms2ger@94.226.67.71) (Ping timeout)
399. # [11:38] <fantasai> tantek: Don't expect to come to a conclusion in this dicussion right now. But wanted to raise the issue and raise the questions that will help us get to a better place.
400. # [11:38] <fantasai> Alan: Right now the only consider is percentage of usage.
401. # [11:38] <fantasai> Alan: If there are other considerations, like users don't care, that should be in that page.
402. # [11:38] <fantasai> s/that/your/
403. # [11:39] <fantasai> Florian: Looking at usage because it can be measured. Whether it breaks the website, much harder to measure.
404. # [11:39] <fantasai> fantasai: I think we can make some subjective judgements on that.
405. # [11:39] <fantasai> Florian: Properties is not the only thing, e.g. gradients.
406. # [11:40] <fantasai> Florian: device-pixel-ratio is another problem.
407. # [11:40] <fantasai> tantek: Here's my challege to non-Webkit vendors.
408. # [11:40] <fantasai> tantek: Please document what properties you're thinking of implementing, and why. The why to me is more important.
409. # [11:40] <fantasai> tantek: Because that is how we will derive methodology to minimize the properties we implement.
410. # [11:41] <fantasai> tantek: I really want to minimize this.
411. # [11:41] <fantasai> glazou: I think it's very unfortunate timing, esp. now that we're trying to use prefixes for JS APIs.
412. # [11:41] <fantasai> glazou: You are solving a problem not with the right way.
413. # [11:41] <fantasai> Florian: give us a better way
414. # [11:41] <fantasai> glazou: You're saying that because you're saying the other ways did not succeed.
415. # [11:42] <fantasai> Florian: We have 15-20 people in devrel, one of their primary jobs is that.
416. # [11:42] <fantasai> Florian: It doesn't scale.
417. # [11:42] <fantasai> tantek: Number of mobile websites providing webkit content first is growing faster than we can contact them.
418. # [11:42] * Joins: danielfilho (danielfilh@187.31.77.7)
419. # [11:42] <fantasai> ...
420. # [11:43] <fantasai> glazou: We're not just here to do things. We're here to do things the right way. We want things to be stable on the Web for 50 years.
421. # [11:43] <fantasai> glazou: The technology, yes, it has to be readable.
422. # [11:43] <fantasai> glazou: I don't think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.
423. # [11:43] <fantasai> sylvaing: Many don't consider the right way to be good.
424. # [11:43] <fantasai> glazou: You don't have to teach me about pragmatism.
425. # [11:44] <fantasai> sylvaing: We have authors who actively write tools to avoid the right wya.
426. # [11:44] <fantasai> tantek: Want to close the discussion with a request for questions and methodology
427. # [11:44] <fantasai> tantek: Request Opera and Microsoft to publish your methodology and what properties you're thinking of implementing.
428. # [11:44] <fantasai> tantek: That way we can minimize the damage.
429. # [11:45] <fantasai> plinss: As soon as we do this, vendor prefixes have failed.
430. # [11:45] <fantasai> tantek: I don't think we need to throw out the baby with the bathwater.
431. # [11:45] <fantasai> plinss: I think the fact that Mozilla is discussing this publicly is harmful.
432. # [11:45] <fantasai> plinss: Nevermind actually doing this.
433. # [11:45] <fantasai> Florian: So what should we do?
434. # [11:45] <fantasai> dbaron: So what should we do, disband the WG?
435. # [11:45] <fantasai> plinss: yes
436. # [11:46] <fantasai> plinss: If we go down this path we have broken standardization.
437. # [11:46] <fantasai> ....
438. # [11:47] <fantasai> plinss: Let's back up a second.
439. # [11:47] <fantasai> plinss: I think Alan raised the best point in this discussion. Your solution doesn't work unless you spoof as someone else.
440. # [11:47] <fantasai> sylvaing: No, we did tests with text-size-adjust, just implementing it was enough.
441. # [11:48] <fantasai> Tab: The biggest thing we're talking about is things like ttransforms. IP is already released.
442. # [11:48] <fantasai> glazou: transforms almost interop, hope you will drop prefixes
443. # [11:48] <fantasai> Tab: If they're thinking of implementing it, then we're probably not able to drop prefixes.
444. # [11:49] <fantasai> Tab: We try to drop prefixes, but some things are too heavily used.
445. # [11:49] <fantasai> Steve: I haven't heard anything new in the last 1/2 hour that I can detect.
446. # [11:49] <fantasai> Steve: I would summarize that there's a practical problem out there, that should be trying to drive features to as quick standardization as possible.
447. # [11:49] <fantasai> Steve: As a way of moving in that direction, attempting to impelemnt an existing prefix is getting a spec out of it.
448. # [11:50] <fantasai> Steve: If we cooperate on documenting what the prefix is, would help us drive towards standardization.
449. # [11:50] <fantasai> glazou: I'm going ot take problem from another point of view, from market pov.
450. # [11:50] <fantasai> glazou: WebKit has a monster advantage out of this situation. Why would they help on standardization?
451. # [11:51] <fantasai> glazou: I'm dead serious? Are you going to help them gain market share by standardization?
452. # [11:51] <fantasai> smfr: We're members of this WG, and accepted the IP implications of that for tansforms and stuff.
453. # [11:51] <fantasai> glazou: But you submitted that directly. But not text-size-adjust.
454. # [11:52] <fantasai> smfr: AFAIK we don't have a reason not to help standardization text-size-adjust.
455. # [11:52] <fantasai> smfr: Think it slipped between the cracks; not enough impetus to standardize it.
456. # [11:52] <fantasai> Alan: Mozilla and Opera have reserachd what are important for them to implement.
457. # [11:52] <fantasai> Alan: The problem for you for this moment, locks in the problem for the rest of time.
458. # [11:52] <fantasai> Alan: One alternative is that we can do this analysis, see here are the ones that it would help us to implement as a prefix, and treat those as house fires.
459. # [11:53] <fantasai> Alan: These are things we need to standardize on *now*.
460. # [11:53] <fantasai> Alan: Make it something that the WG finalizes within the next 3 months.
461. # [11:53] <fantasai> Alan: Go out and say, here is the unprefixed properties. Get the word out.
462. # [11:53] <fantasai> Alan: You fix the problem in a better way.
463. # [11:53] <fantasai> Alan: Lose out a percentage on websites that won't get updated.
464. # [11:53] <fantasai> Alan: But you stop the problem there.
465. # [11:54] <fantasai> Florian: We have everything to gain by reducing the number of times there is a non-standard property used by a large number of websites.
466. # [11:54] <fantasai> Florian: Yes we should minimize such situations.
467. # [11:54] <fantasai> Florian: That will help in the future. But won't fix body of content already out there.
468. # [11:54] <fantasai> Alan: Regardless of whether you implement those prefixes, this WG needs to prioritize the work accordingly.
469. # [11:54] <fantasai> Florian: Strongly agree. Yet I think it is not enough.
470. # [11:55] <fantasai> plinss: Thing we need to spend some energy minimizing the escape of prefixes into the wild
471. # [11:55] <fantasai> plinss: Fact that production sites use them, it's okay if it makes it slightly prettier, but if not supporting breaks the site, then that's a problem.
472. # [11:55] <fantasai> Alan: Devrel can't seem to get on top of that. Only thing this WG can do is not put them in releases.
473. # [11:56] <fantasai> plinss: Should discuss putting experimental propertie sonly in experimental builds.
474. # [11:56] <fantasai> howcome: Should maybe put out a call to web authors to stop this.
475. # [11:56] <fantasai> jdaggett: I think strategy of just pretending to be -webkit-, without any attempt ...
476. # [11:57] <fantasai> jdaggett: You need to make public statements like "Here is an example of a presenter presenting -webkit- things as if they are a standard, and they are not."
477. # [11:57] <fantasai> jdaggett: Need multiple people here to dothat.
478. # [11:57] <fantasai> howcome: Including Apple.
479. # [11:57] <fantasai> ...
480. # [11:58] <fantasai> Steve: Philosophical point. Standardization, when you control the consumers and the generators, is much easier.
481. # [11:58] <fantasai> Steve: In good old days of telephones, ppl who made telephones and ppl who installed telephones were relatively small set. could get interoperable standards and it worked.
482. # [11:58] <fantasai> Steve: We are operating in an environment where we can't control users of our standards. We can influence them, that's point being made; but too many of them doing too little reading that we can impact them.
483. # [11:58] <fantasai> Steve: This is just life.
484. # [11:59] <fantasai> fantasai: Having standards advocates advocate prefixes is making the problem worse, cutting that off would improve the situation.
485. # [12:00] <fantasai> tantek: Florian's point that we're competing against Flash and mobile apps is important.
486. # [12:00] <fantasai> tantek: Telling web developers to stop using webkit properties would mean they stop writing web apps.
487. # [12:01] <fantasai> tantek: I think it's great that Apple wants to innovate as fast as they can. I would prefer they propose to the WG, if not before implementation, then when implementing. If not then, at least when shipping. If not then with a few months, Simon?
488. # [12:01] <fantasai> tantek: I don't want Apple to slow down in innovation and implementing new things. THat helps the Web grow and innovate.
489. # [12:02] <fantasai> plinss: Your point about if people can't write webkit properties they'll write a web app --
490. # [12:02] <fantasai> plinss: I would rather they write an iphone app than they write a web app that only works on webkit.
491. # [12:02] <fantasai> plinss: There's no advantage to the Web ot have someone write a platform-specific website.
492. # [12:02] <fantasai> tantek disagrees.
493. # [12:03] <fantasai> Anton: I think it'll be very dangerous to make it obvious that we can implement each others prefixes without making it very clear what vendor prefixes are and how they're supposed to work.
494. # [12:03] <fantasai> Anton: Need the WG to agree and explain what problem they're trying to solve with prefixes.
495. # [12:04] <fantasai> Anton: I think it is harmful to concentrate on this one problem and not concentrate on the global problem. Send a very mixed message to authors.
496. # [12:05] <fantasai> plinss: You're telling authors to just use webkit prefixes, we'll make it work.
497. # [12:05] <fantasai> Tantek: No, we're only implementing a small minimized number of these.
498. # [12:06] <fantasai> fantasai: But if you don't make that clear, and communicate that, it'll be interpreted as "if enough websites use it they will implement it".
499. # [12:06] <fantasai> fantasai: Anton's point is that you need to send that message, and not just in the CSSWG minutes.
500. # [12:06] <fantasai> glazou: If the user requests another -webkit- property, they will implement it. It's a Pandora's box.
501. # [12:07] <fantasai> sylvaing: Listening to the conversation, sounds like this proposal is a big injury to the Web, that prefixes are a [...].
502. # [12:07] <fantasai> sylvaing: I've sat in conferences where Eric Meyer show how to use prefixes and then put unprefixed version for "future proofing"
503. # [12:07] <fantasai> sylvaing: Nobody gets it.
504. # [12:08] <dbaron> q+ to compare our situation to ietf's "rough consensus and running code"
505. # [12:08] <fantasai> sylvaing: We have people trying to evade the system. Problem is large.
506. # [12:08] <fantasai> sylvaing: Prefixing works on theory in paper, and out in the real world everybody hates it.
507. # [12:08] <fantasai> glazou: There's at least one way it didn't fail.
508. # [12:08] <fantasai> glazou: If you use -moz- prefix, you have to test it in Mozilla
509. # [12:08] <fantasai> glazou: If you use -webkit- you know it will only work in WebKit.
510. # [12:09] <fantasai> sylvaing: The advice being given now is to include the unprefixed version. The system works in theory, in practice it doesn't work.
511. # [12:09] <fantasai> tantek: My experience with Authors is that they Hate using prefixes.
512. # [12:09] <fantasai> tantek: if anything, they are annoyed with the CSSWG for taking so long to get specs to the point where they can be unprefixed.
513. # [12:10] <fantasai> tantek: They complain that CSSWG takes too long.
514. # [12:10] <fantasai> tantek: Second reason is they are evangelized to use prefixed stuff, e.g. -webkit-
515. # [12:10] <fantasai> sylvaing: The people who think prefixing is a good feature, majority of them are in this room.
516. # [12:11] <fantasai> glazou: Even if we only take 3 months from FPWD to unprefixed, it's too slow cmp shipping.
517. # [12:11] <fantasai> Tab: We can break some people. But not everyone.
518. # [12:11] <fantasai> glazou: Transforms emerged not long ago. Web is full of them.
519. # [12:11] <fantasai> glazou: It took 3 months to have real life examples of ppl using transforms.
520. # [12:11] <fantasai> Tab: I thought 2D transforms have been around for a while.
521. # [12:11] <fantasai> Steve: Are we getting somewhere?>
522. # [12:12] <fantasai> tantek: I tried to close once with request with more questions.
523. # [12:12] <fantasai> glazou: Seems that the 3 browser vendors here have already decided.
524. # [12:12] <fantasai> dbaron: I think one of the underlying problems here..
525. # [12:12] <fantasai> dbaron: The IETF has a motto "rough consensus and running consensus"
526. # [12:12] <fantasai> dbaron: I haven't deal with them much. But I think one of the problems I sense in this group
527. # [12:13] <glazou> s/running consensus/running code
528. # [12:13] <fantasai> dbaron: is that it's just as easy to hold up a specification that has no implementations as it is to hold up a spec that's got 4 implementations and everyone pushing to use it.
529. # [12:13] <fantasai> dbaron: There should be a bias based on what the real state of something is.
530. # [12:13] <fantasai> dbaron: What the state of implementations is.
531. # [12:13] <fantasai> dbaron: When we've got something like 2D transforms thats implemented in 4 major browsers and
532. # [12:14] <fantasai> dbaron: Should be harder to put process blocks on that spec.
533. # [12:14] <fantasai> dbaron: We have a test suite now, but we've agreed to abandon the spec.
534. # [12:14] <fantasai> alexmog: I think impelmentations should use -rfc3300- prefix
535. # [12:15] <fantasai> alexmog: have a draft that defines what that means, experiment with it
536. # [12:15] <fantasai> alexmog: if it fails, it fails, if it succeeds, it's defined what it is
537. # [12:15] <fantasai> sylvaing: ?
538. # [12:15] <fantasai> alexmog: Not different from today, but don't have the moral problem of implementing another vendor's prefix
539. # [12:16] <fantasai> Steve: First, RFCs are specifically withdrawn after 6 months. Spec disappears by definition.
540. # [12:16] <fantasai> dbaron: That's a draft. Not RFC
541. # [12:16] <fantasai> Steve: We're not talking about specs. For the suer to use things, there has to be documentation for the user.
542. # [12:16] <fantasai> Steve: The problem is asking for documentation sufficiently well-specified for interop
543. # [12:17] <fantasai> sylvaing: Both us and Apple document our things on our site, but not enough for standardization
544. # [12:17] <fantasai> Steve: Suggest that group establish a goal that members who introduce experimental properties submit a description to the W
545. # [12:17] <fantasai> Steve: Maybe it just goes into a file somewhere, until someone wants to follow up
546. # [12:17] <fantasai> Steve: But at least it becomes available to the WG, which Tantek was requesting.
547. # [12:18] <fantasai> Florian: Said that there's no progress in this conversation.
548. # [12:18] <fantasai> Florian: Some people are saying don't do this. But all the vendors need to do this.
549. # [12:18] <fantasai> Florian: Blocking the conversation here just means don't do this in this room.
550. # [12:18] <fantasai> Florian: The idea is to discuss the how.
551. # [12:18] <fantasai> plinss: We haven't spent any time discussing how not to do this.
552. # [12:19] <fantasai> Florian: I think we did enough on why.
553. # [12:19] <fantasai> plinss: Only if the what else has failed should we go onto how.
554. # [12:19] <fantasai> plinss: You have tried and failed individually. Not as a group.
555. # [12:19] <fantasai> dbaron: a year ago we tried to discuss dropping prefixes before CR, and failed at that.
556. # [12:19] <fantasai> fantasai: No, you added additional requirement of having the test suite.
557. # [12:20] <fantasai> plinss: If you have a list of properties you have to implement to survive, then let's get that list, get consensus on it, and then agree to standardize them as-is implemented in WebKit.
558. # [12:20] <fantasai> Florian: That only stops the bleeding.
559. # [12:21] <fantasai> plinss: If we do this without a plan to stop the bleeding, it's only going to get worse.
560. # [12:21] <fantasai> Anton: And will cause confusion.
561. # [12:21] <fantasai> plinss: To go back to Quirks mode. The original intention -- it was intended for NS4, btw, not IE6 -- the problem was too many sites to fix, we have to support them.
562. # [12:22] <fantasai> plinss: But we wanted to support only the old sites, and new sites should be written to standard
563. # [12:22] <fantasai> plinss: People are still writing sites today that depend on quirks mode in order to function.
564. # [12:22] <fantasai> plinss: People 20 years from now will be writing sites that support webkit prefxes.
565. # [12:23] <fantasai> dbaron: There's a major piece of Web standards ocmmunity, not well represented in this room, but better rpersented in HTML and WHATWG
566. # [12:23] <fantasai> dbaron: They think quirks mode was a mistake. That we should have just lived with that behavior.
567. # [12:23] <fantasai> plinss: I accept that as a philosophy, but that was impossible.
568. # [12:23] <fantasai> plinss: NS4 did not treat HTML as a structured document.
569. # [12:23] <fantasai> dbaron: I think quirks mode very quickly diverged from its original intent
570. # [12:23] <fantasai> dbaron: Because 2 years after IE had 95%+ market share
571. # [12:24] <fantasai> dbaron: It became about bieng compatible with IE, not NS4.
572. # [12:24] <fantasai> plinss: If we launch this vendor-prefixed quirks mode, it's going to get out of hand. Whatever our desire to minimize our impact, it's going to get worse than what we expect.
573. # [12:24] <fantasai> Florian: Not spread to everything
574. # [12:24] <fantasai> plinss: Going to get worse than you expect
575. # [12:25] <fantasai> dbaron: Email headers with X-. Supposed to be experimental. But the world still works.
576. # [12:25] <fantasai> tantek: While I understand the analogy, I disagree
577. # [12:25] <fantasai> tantek: We can search for and get data on prefixed property use
578. # [12:25] <fantasai> tantek: You can write a linter that points out your webkit properties.
579. # [12:26] <fantasai> tantek: quirks mode you can start relying on accidentally
580. # [12:26] <fantasai> tantek: I don't think this is as bad as quirks mode.
581. # [12:26] <fantasai> tantek: Quirks mode biased being lazy.
582. # [12:26] <fantasai> tantek: The policy we have for prefixes biases the right thing, which is no prefix.
583. # [12:26] <fantasai> tantek: It takes work to use a prefix, whereas it didn't take work to use Quirks mode.
584. # [12:26] <fantasai> tantek: i can see the similaritie,s but in practice I think they're very different.
585. # [12:26] <fantasai> plinss: My assertion is that it's still going to be worse than you think.
586. # [12:27] <fantasai> plinss: People will write tools and inject things, etc.
587. # [12:27] <fantasai> plinss: Authors are going to have this happen to them, because of tools.
588. # [12:27] <fantasai> sylvaing: Once those -webkit- propertie work in other rowsers, are people going to check which ones work? Or are they just going to assume that all -webkit- properties work?
589. # [12:28] <fantasai> tantek: It is up to us to make sure that the unprefixed properties are the most reliable.
590. # [12:28] <fantasai> tantek: And that's how we end up driving off the -webkit-
591. # [12:28] <fantasai> tantek: Being neat only drives authors so far. They want reliability. If we can deliver that with unprefixed
592. # [12:29] <fantasai> plinss: We need to get in people's minds that if you use prefixed, we will drop support for it at some point.
593. # [12:29] <fantasai> plinss: We should assert leverage to get MS and Webkit to change their mind.
594. # [12:29] <fantasai> plinss: Prefix has half-life. It will live for so many years, then go away, by definition. That will help this problem.
595. # [12:29] <fantasai> plinss: If we can get something like that stuck in the ground, then my objection drops dramatically. Because we've cut the bleeding.
596. # [12:29] <fantasai> glazou: I heard earlier that prefixes are bug not a feature.
597. # [12:30] <fantasai> glazou: Prefixes for web authors, they don't think it's a bug. They think it's a burden. it's not the same thing.
598. # [12:30] <fantasai> glazou: It's a burden b/c they don't know how long they have to maintain them.
599. # [12:30] <fantasai> glazou: If prefixes were only impelmented for 3 years, that would help.
600. # [12:30] <fantasai> tantek: mozilla has a policy of dropping prefixes when we implement unprefixed
601. # [12:31] <fantasai> tantek: Web authors can know just by Mozilla, that prefixes are uncertain.
602. # [12:31] <fantasai> tantek: IE10 broke many things. I would not be sur[rised if MS will drop prefixes at some point.
603. # [12:31] * Quits: jdaggett (jdaggett@128.93.134.208) (Quit: jdaggett)
604. # [12:32] <fantasai> fantasai: We would not be having this conversation if mobile did not exist, correct?
605. # [12:32] <sylvaing> note that IE10 dropped legacy features from *standard mode*
606. # [12:32] <fantasai> agreement
607. # [12:32] <sylvaing> Trident still includes legacy features for older docmodes; the latter are necessary for intranets for instance
608. # [12:33] * Quits: smfr (smfr@128.93.135.37) (Quit: smfr)
609. # [12:33] * Quits: dbaron (dbaron@128.93.135.77) (Quit: 8403864 bytes have been tenured, next gc will be global.)
610. # [12:33] * Quits: Rossen (Rossen@128.93.134.228) (Ping timeout)
611. # [12:33] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
612. # [12:34] <fantasai> fantasai: What if -webkit- was implemented only for mobile? That would add the unreliability factor that Tantek was asking for, because it would not work on desktop. And that would bias authors to using unprefixed, which is what we want.
613. # [12:34] * plinss is now known as plinss_away
614. # [12:34] * Quits: vincent_ (qw3birc@128.30.52.28) (Ping timeout)
615. # [12:34] <fantasai> <br type=lunch>
616. # [12:34] * Quits: astearns (qw3birc@128.30.52.28) (Ping timeout)
617. # [12:35] * Quits: florian (florianr@128.93.135.13) (Ping timeout)
618. # [12:35] * Quits: sylvaing (sylvaing@128.93.135.76) (Ping timeout)
619. # [12:35] * sylvaing_away is now known as sylvaing
620. # [12:44] * Quits: jet (jet@128.93.134.212) (Quit: jet)
621. # [12:55] * Joins: Ms2ger (Ms2ger@94.226.67.71)
622. # [13:25] * Joins: karl (karlcow@128.30.54.58)
623. # [13:49] * Joins: jet (jet@128.93.134.212)
624. # [13:50] * Joins: jdaggett (jdaggett@128.93.134.208)
625. # [13:50] * Joins: astearns (qw3birc@128.30.52.28)
626. # [13:52] * plinss_away is now known as plinss
627. # [13:52] * Joins: sgalineau (sylvaing@128.93.135.76)
628. # [13:52] * Joins: smfr (smfr@128.93.135.37)
629. # [13:53] * jdaggett scratches head...
630. # [13:53] * Joins: TabAtkins_ (tabatkins@74.125.122.49)
631. # [13:55] * Quits: jet (jet@128.93.134.212) (Quit: jet)
632. # [13:55] * Joins: jet (jet@128.93.134.212)
633. # [13:56] * Bert reached Chris, he won't join today.
634. # [13:56] * Quits: smfr (smfr@128.93.135.37) (Quit: smfr)
635. # [13:56] * Joins: smfr (smfr@128.93.135.37)
636. # [13:58] * Joins: kojiishi (kojiishi@128.93.135.158)
637. # [14:01] * Joins: glazou (glazou@128.93.135.193)
638. # [14:04] <glazou> for those who know hil, Tristan Nitot from Mozilla Europe says hi
639. # [14:04] <glazou> s/hil/him
640. # [14:05] * Joins: Rossen (Rossen@128.93.134.228)
641. # [14:05] * sgalineau doesn't know Tristan, but knows of Tristan....
642. # [14:07] * Joins: vhardy_ (qw3birc@128.30.52.28)
643. # [14:07] <fantasai> jdaggett, what were the issues that you raised about? (other than @text-transform)
644. # [14:08] * fantasai only knows about the issues in http://www.w3.org/Style/CSS/Tracker/products/10
645. # [14:08] * Joins: dbaron (dbaron@128.93.135.77)
646. # [14:08] <TabAtkins_> ScribeNick: TabAtkins_
647. # [14:09] <jdaggett> fantasai: i'm on drugs, issues were in writing-modes
648. # [14:09] <jdaggett> fantasai: but text-transform will take a bit of time i think
649. # [14:09] <TabAtkins_> florian: When a browser supports several variants of the same property (either prefixed and unprefixed, or multiple prefixed), what does it look like through the OM?
650. # [14:10] <TabAtkins_> florian: If we favor interop here, we should decide what it says.
651. # [14:10] <TabAtkins_> florian: But David argues that we shouldn't favor interop here - the fragility helps discourage prefix usage.
652. # [14:10] <TabAtkins_> [some discussion over one impl strategy]
653. # [14:10] <TabAtkins_> florian: Another strategy is to always favor your impl, as it can let someone target your impl well.
654. # [14:11] <TabAtkins_> sylvaing: What do browsers do today?
655. # [14:11] <TabAtkins_> florian: We don't have a problem with it yet.
656. # [14:11] <TabAtkins_> dbaron: Gecko never implements different semantics for two things.
657. # [14:11] <TabAtkins_> dbaron: The only time we've had two things in gecko is with prefixed and unprefixed.
658. # [14:11] <TabAtkins_> dbaron: When we did that, -moz- was treated as an alias for unprefixed.
659. # [14:11] <fantasai> jdaggett, my plan is to cut anything that has issues that can't be solved between now and march 1st
660. # [14:12] <TabAtkins_> dbaron: If you asked for the -moz- in the OM, you'd get back the unprefixed.
661. # [14:12] <TabAtkins_> dbaron: If you got the list of properties, you'd get the unprefixed as well.
662. # [14:12] <jdaggett> fantasai: in text? writing modes?
663. # [14:12] <TabAtkins_> dbaron: It was meant to steer people toward the unprefixed.
664. # [14:12] <TabAtkins_> dbaron: Webkit supports multiple prefixes with different semantics.
665. # [14:13] <TabAtkins_> alexmog: In general, only cascading should matter. If a dev puts it there, it means that they want it.
666. # [14:13] <TabAtkins_> alexmog: If you have two prefixes, you should favor your own.
667. # [14:13] <TabAtkins_> TabAtkins_: What about -webkit- and -epub-?
668. # [14:13] <TabAtkins_> alexmog: You should favor the -webkit-.
669. # [14:14] <TabAtkins_> sylvaing: Why is it different from prefixed and unprefixed?
670. # [14:14] <TabAtkins_> alexmog: I need to be able to target specific impls.
671. # [14:14] <fantasai> jdaggett, text
672. # [14:15] <TabAtkins_> sylvaing: So if -webkit- is supported by Opera and it's the last one, what happens?
673. # [14:15] <fantasai> jdaggett, unfortunately white space processing is not optional, so I have to fix all the issues in it anyway :)
674. # [14:15] <fantasai> away
675. # [14:15] <jdaggett> fantasai: so you're shooting for LPWD at end of march?
676. # [14:15] <TabAtkins_> florian: If you set up a hierarchy (your prefix is stronger than othe rprefix, unprefixed is most important), what happens if you have different specificity/important?
677. # [14:16] <TabAtkins_> sylvaing: We had that with 'opacity' and 'filter'.
678. # [14:16] <fantasai> jdaggett, shooting for the beginning of march, hopefully make it by the end :)
679. # [14:17] <TabAtkins_> florian: Back to David's original point, do we *want* to synchronize, or is it a feature that we're all different?
680. # [14:17] <TabAtkins_> plinss: I question whether we need to standardize on something vendor-specific.
681. # [14:17] <TabAtkins_> florian: The problem is that authors should have a reliable way, when reading stylesheets from JS, knowing which one will work.
682. # [14:18] <TabAtkins_> florian: Does putting the unprefixed last guarantee that it'll be the one that's chosen (when selected), or might some prefixes win anyway?
683. # [14:18] <TabAtkins_> plinss: In general, I don't like adding feature to help people work around vendor bugs.
684. # [14:19] <TabAtkins_> plinss: I think it's fair that vendors put in special-case code.
685. # [14:20] <TabAtkins_> florian: I would be happy if the WG said that, when prefixes are used, they alias and are chosen in turn by the normal cascade.
686. # [14:20] <TabAtkins_> florian: Also, do multiple versions of a property all survive to the OM?
687. # [14:21] <TabAtkins_> Rossen: If they're aliases, they should all point to the same thing. If they're not, they should point to different things.
688. # [14:22] <TabAtkins_> TabAtkins_: [explains WebKit's behavior - generally, they're aliases in the stylesheet, but separate in the OM]
689. # [14:22] <TabAtkins_> florian: I remember what was said.
690. # [14:23] <TabAtkins_> florian: If you use multiple versions in the stylesheet, then all are preserved in the specified value, but only the "winning" one lives in the computed style.
691. # [14:24] <TabAtkins_> TabAtkins_: But Gecko always returns the unprefixed version in the computed style - they don't remember the source.
692. # [14:25] <TabAtkins_> fantasai: We have some unprefixed aliasing too - overflow-wrap and word-wrap are (unprefixed) aliases.
693. # [14:25] <TabAtkins_> dbaron: I don't think we should have aliases in the spec.
694. # [14:26] <TabAtkins_> florian: I think it's reasonable, even if it's just an optional alias. We should still define how the cascade and OM work for them.
695. # [14:27] <TabAtkins_> florian: I propose that it gets converted to the "most standard" one, and it appears as that in all cases in the OM.
696. # [14:27] <TabAtkins_> fantasai: We also have page-break-* and break-*.
697. # [14:27] <TabAtkins_> fantasai: I need to put that into a spec. So we need a resolution for this.
698. # [14:27] <TabAtkins_> sylvaing: I'd like to see some testcases, if someone needs to change.
699. # [14:28] <TabAtkins_> sylvaing: In the case of filter/opacity, it depends on document mode.
700. # [14:28] <TabAtkins_> [something about the specifics of IE modes]
701. # [14:28] <TabAtkins_> plinss: When it comes to aliases, has anyone implemented those yet?
702. # [14:29] * Joins: florian (florianr@128.93.135.13)
703. # [14:29] <TabAtkins_> howcome: I think we support break-*, and page-break-*. I don't think we do column-break-*
704. # [14:30] <TabAtkins_> howcome: I'm not sure what we do with the OM.
705. # [14:31] <TabAtkins_> szilles: For "most standard", if I have -webkit- and -epub-, which is most standard?
706. # [14:33] <TabAtkins_> tantek: I think that Moz always converts to unprefixed in the OM.
707. # [14:33] <TabAtkins_> [several moz people]: No, that's not what happens.
708. # [14:34] * Quits: vhardy_ (qw3birc@128.30.52.28) (Ping timeout)
709. # [14:34] <TabAtkins_> plinss: Maybe that's a good approach, though. Just *never* show prefixed in the OM.
710. # [14:34] <TabAtkins_> TabAtkins_: That seems reasonable to me.
711. # [14:34] <TabAtkins_> glazou: And what about when serialized?
712. # [14:34] <TabAtkins_> plinss: Serialization is different.
713. # [14:34] <fantasai> chair overrides speaker, but minute-taker overrides chair :p
714. # [14:35] <TabAtkins_> glazou: If it doesn't show up in the OM at all (when an unprefixed doesn't exist yet), that will break editors.
715. # [14:35] <TabAtkins_> tantek: We set a precedent ofr prefixing in the DOM, too.
716. # [14:35] <TabAtkins_> tantek: We probably want to keep things prefixed in the OM, then, so we can justify other web apis prefixing.
717. # [14:36] <sgalineau> if one supports -prefix-foo and foo and the stylesheet only sets -prefix-foo, does getComputedStyle() expose it as prefixFoo or foo ?
718. # [14:37] <TabAtkins_> florian: The simplest thing we can do is that, at the cascading level, the last one wins.
719. # [14:37] <TabAtkins_> florian: In the OM, the one that's used is returned.
720. # [14:38] <TabAtkins_> dbaron: I don't see any need to remember prefixes in Gecko.
721. # [14:38] <TabAtkins_> macpherson: I think the most consistent is to reflect the used version.
722. # [14:38] <TabAtkins_> macpherson: If we change the spec after implementation, you'll need to return the value in the old form as a prefix.
723. # [14:39] <TabAtkins_> dbaron: Part of the Gecko strategy to discourage prefixes is that, the *instant* the unprefixed is supported, the OM no longer supports th eprefix.
724. # [14:39] <TabAtkins_> dbaron: We may support it still in the stylesheet for a bit, as necessary.
725. # [14:40] <TabAtkins_> plinss: Our policy should be to keep prefixes fragile.
726. # [14:40] <TabAtkins_> TabAtkins_: Yes.
727. # [14:40] <TabAtkins_> plinss: If you use prefixes, here be dragons, and we won't help you keep it working.
728. # [14:40] <TabAtkins_> jdaggett: While members are cool with that, their companies have marketing departments that may not agree.
729. # [14:41] <TabAtkins_> macpherson: I think you can handle that by just dropping when we can, not by *forcing* prefixes to break automatically.
730. # [14:42] <TabAtkins_> sylvaing: We shouldn't punish success.
731. # [14:42] <TabAtkins_> florian: So should we preserve the prefix or not?
732. # [14:42] <TabAtkins_> dbaron: We haven't had content breaking because of dropping th eprefix in the OM.
733. # [14:42] <TabAtkins_> smfr: We probably would have content break in WebKit if we did that.
734. # [14:43] <TabAtkins_> florian: As an editor, Daniel, do you prefer what the stylesheet originally said, or what is used?
735. # [14:43] <TabAtkins_> glazou: From a CSS editing program, I'd prefer getting back *everything*. But at least, what the author said.
736. # [14:44] <TabAtkins_> glazou: If an editor changes properties between input and output, we'd just get complaints from users.
737. # [14:45] <TabAtkins_> florian: By now I know what I want to ipmlement, so I wonder if we should consider discussing until we agree on what to implement, or if we should learn to love the breakage.
738. # [14:45] <TabAtkins_> florian: The cascade wins (the one that comes last). When you query through the OM, you only see the one that won (with or without prefix, depending on which one won).
739. # [14:46] <TabAtkins_> florian: So internally you remember which name was used, but you otherwise treat them as aliases.
740. # [14:46] * Quits: Rossen (Rossen@128.93.134.228) (Ping timeout)
741. # [14:47] <TabAtkins_> glazou: Say that Opera supports a -webkit- property, and -webkit- drops its prefix.
742. # [14:47] <TabAtkins_> glazou: Before you drop the prefix too, if -webkit- is used last, you'll output the -webkit- rule in the OM, even though it will no longer work in WebKit.
743. # [14:48] <TabAtkins_> florian: Yes. That's internally consistent.
744. # [14:48] <TabAtkins_> glazou: But you have inconsistencies for a little while.
745. # [14:49] <TabAtkins_> glazou: My preference would go to supporting the last one in implementation order, not cascading.
746. # [14:49] <TabAtkins_> florian: When a page is authored toward a particular prefix in script, that'll break the page.
747. # [14:49] <TabAtkins_> alexmog: I can explain what we might think of doing.
748. # [14:49] <TabAtkins_> alexmog: We preserve all the properties that are set.
749. # [14:50] <TabAtkins_> alexmog: So if you write out a file, we'll write out everything.
750. # [14:50] * Joins: Rossen (Rossen@128.93.134.228)
751. # [14:50] <TabAtkins_> alexmog: If you query through the OM, we only preserve one of the values after cascading.
752. # [14:50] <TabAtkins_> alexmog: If hypothetically we have -ms- and -webkit- and unprefixed, all will return the appropriate syntax, but from only the winning value.
753. # [14:50] <TabAtkins_> florian: If the -webkit- won the cascade, do you see it as -webkit-, or as something else, or as all of them?
754. # [14:52] <TabAtkins_> alexmog: So if we support multiple names for a property, we'll return the winning declaration as *all* of them (perhaps with adjusted syntax, as necessary).
755. # [14:52] <TabAtkins_> alexmog: So we probably wont' want to remember who won.
756. # [14:53] <TabAtkins_> szilles: What do you do if the values changed between property versions?
757. # [14:53] <TabAtkins_> alexmog: We'll adjust the output to match the syntax of the given version.
758. # [14:53] <TabAtkins_> Rossen: I don't think that's right.
759. #
760. # Session Start: Mon Feb 06 15:09:03 2012
761. # Session Ident: #css
762. # [15:09] * Now talking in #css
763. # [15:09] * Topic is 'CSS Working Group | logged at http://krijnhoetmer.nl/irc-logs/'
764. # [15:09] * Set by dbaron on Wed Oct 12 01:04:03
765. # [15:09] <TabAtkins_> RESOLVED: The last resolution applies to WG-approved aliases. It may be used by browsers for prefixed versions as well.
766. # [15:09] <TabAtkins_> florian: Now, for prefixed values.
767. # [15:10] <TabAtkins_> florian: I say just return the one you got.
768. # [15:10] <TabAtkins_> plinss: Agreed.
769. # [15:10] <TabAtkins_> TabAtkins_: Agreed.
770. # [15:11] <TabAtkins_> Florian: What about individual media query features?
771. # [15:12] <TabAtkins_> TabAtkins_: I think they feel a little more like values, so I'd preserve them as the author wrote.
772. # [15:12] <TabAtkins_> florian: Does anyone who cares object?
773. # [15:13] <TabAtkins_> fantasai: Deferring to dbaron.
774. # [15:13] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
775. # [15:13] <TabAtkins_> plinss: The point for properties is so we don't have to remember which version it came from.
776. # [15:14] <TabAtkins_> florian: But for values we reasonably often can't cover all the possibilities between versions.
777. # [15:14] * Joins: vhardy_ (qw3birc@128.30.52.28)
778. # [15:15] <TabAtkins_> RESOLVED: When value aliases are supported, return the version that the author provided.
779. # [15:16] <TabAtkins_> RESOLVED: In media query feature strings, also return the version that the author provided.
780. # [15:16] <florian> ScribeNick: florian
781. # [15:16] <florian> Topic: Functional notation
782. # [15:16] <fantasai> http://wiki.csswg.org/ideas/functional-notation
783. # [15:17] <florian> fantasai: Tab and I have review functional notation through all specs to try and see what can be aligned
784. # [15:17] <florian> s/review/reviewed/
785. # [15:18] <florian> fantasai: priciples: coma is the lowest priority
786. # [15:19] <Bert> s/coma/comma/
787. # [15:19] <florian> fantasai: if a value is optional, you can leave it out in functional syntax just as in the rest of css
788. # [15:19] <Bert> s/priciples/principles/
789. # [15:20] <florian> tab: Inside a function, things should be just like they are on any property
790. # [15:20] <florian> Hakon: we created functional notation to have ordering
791. # [15:20] <florian> Tab: no, it was created to have grouping
792. # [15:20] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jan/0933.html
793. # [15:20] <florian> Tab: css already has ordering. The only thing functional notation gives you is grouping
794. # [15:21] <florian> Hakon: but generally, ordering is not expected,
795. # [15:22] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
796. # [15:22] <RRSAgent> logging to http://www.w3.org/2012/02/06-css-irc
797. # [15:22] <florian> howcome: in functional notation, commas should separated ordered parameters, just like they do in other languages
798. # [15:23] <florian> howcome: the proposal makes some sense, but the cost of changing is too hight compared to the benefit
799. # [15:24] <florian> tab: most properties try to have arguments that can be reordered, unless that gives some ambiguity
800. # [15:24] <florian> tab: functions should do the same, but currently, they don't
801. # [15:24] <Bert> s/hight/high/
802. # [15:25] * Quits: vhardy_ (qw3birc@128.30.52.28) (Quit: Page closed)
803. # [15:25] <florian> fantasai: allowing reordering within functional notation also makes it possible for things to be optional
804. # [15:25] <fantasai> fantasai: optionality makes it possible to extend functionality later
805. # [15:27] <florian> steeve: with a naive understanding of functions, I expect ordering
806. # [15:27] <florian> florain: these are not functions
807. # [15:27] <florian> glazou: people will still see them as such
808. # [15:28] <florian> howcome: don't change the meaning of commas
809. # [15:29] <florian> fantasai: let's look at some examples
810. # [15:29] <sgalineau> I think the combination of CSS2.1 precedent and average JS programmer habit creates an expectation of commas a separators between each value
811. # [15:29] * Joins: nimbu (Adium@24.18.47.160)
812. # [15:30] <florian> fantasai: see the wiki for examples
813. # [15:30] <florian> dbaron: it would have been ok to change a few years ago, but not now
814. # [15:31] <florian> dbaron: we should push transforms 3 as it is, and introduce a new syntax in a later level
815. # [15:31] <florian> *: general agreement
816. # [15:32] <florian> howcome: how are they done in fortran
817. # [15:32] <florian> ?
818. # [15:33] <florian> sylvian: are users going to remember this?
819. # [15:33] * Joins: howcome (howcome@128.93.135.53)
820. # [15:33] <florian> florian: they do for regular properties
821. # [15:34] <florian> tab: the benefits are reordering and optionality
822. # [15:35] <florian> tantek: did we ever get stuck due to the lack of reordering or optionality?
823. # [15:35] <florian> tab: on gradients
824. # [15:36] <dbaron> dbaron: I'm not comfortable using the word "fixed" for gradients
825. # [15:36] <sgalineau> the issue is not whether the new notation helps feature design, but whether it may confuse feature users
826. # [15:36] <dbaron> s/not comfortable/not yet comfortable/
827. # [15:36] <florian> jdagget: of the things on this wiki, I don't see any that benefit from the extensibility argument
828. # [15:37] <florian> plinss: you don't know what you want to extend until you try to
829. # [15:38] <florian> glazou: translate(x,y) to translate(x y) is useless
830. # [15:38] <florian> fantasai: it is for consistency with other places that have an x and a y
831. # [15:38] <fantasai> background-position, background-size
832. # [15:39] * sgalineau wants a polish-* version of CSS functions....OK, not really
833. # [15:39] <florian> plinss: even if some case don't benefit individually, consistency is good
834. # [15:40] <florian> tab: we didn't suggest any change to gcpm because everything was either ok or consistent with some established thing
835. # [15:41] <florian> fantasai reads the proposal for animations (steps and cubic-bezier)
836. # [15:42] <florian> tab: polygons would be nicer as a list of points than a list of numbers
837. # [15:42] <dbaron> So how many browser implementations of cubic-bezier() do we have now? 4, right?
838. # [15:44] <florian> florian: let's not break support for things that are interoperably implemented, even if they are currently prefixed
839. # [15:45] <florian> glazou: does any tool support this syntax already?
840. # [15:45] <florian> tab: no, it is a new proposall
841. # [15:46] <florian> plinss: on matrices, commas, spaces, whatever doesn't really matter
842. # [15:46] * dbaron wonders if we should also allow the function name to optionally be spelled as cubic-bézier() :-)
843. # [15:47] <florian> fantasai: if we want to make commas optionals, we need to do it now, otherwise people won't ever use it?
844. # [15:47] <florian> plinss: I don't want to hold specs due to this
845. # [15:48] <Bert> s/proposall/proposal/
846. # [15:48] <florian> plinss: as a general principle, as soon as we have experimental implementations, it should be the focus of the wg to drive that to rec asap
847. # [15:49] * Ms2ger notes http://lists.w3.org/Archives/Public/www-style/2009Feb/0518.html
848. # [15:49] <florian> tab: there are a few ones that haven't been implemented yet
849. # [15:50] <florian> fantasai: merge the rectangle notation with the rect notation in exclusions
850. # [15:51] <smfr> css2 rect: http://www.w3.org/TR/CSS2/visufx.html#clipping
851. # [15:52] <smfr> exclusions rectangle: http://dev.w3.org/csswg/css3-exclusions/#shapes-from-svg-syntax
852. # [15:53] <florian> vincent: overall, we are ok with the changes suggested for exclusions
853. # [15:53] * glazou wonders who commited 5 css3-images CVS changes 7 minutes ago in the middle of the meeting :-D
854. # [15:55] <dbaron> http://www.w3.org/TR/WD-positioning-970131
855. # [15:55] <florian> tab: let's drop the suggestion to merge with rect
856. # [15:57] <florian> fantasai: for values and units, in attr, we want to drop the comma between the name and the type, because they are paired, and keep the comma that separates that from the fallback
857. # [15:57] * Quits: drublic (drublic@88.74.75.215) (Client exited)
858. # [15:58] <florian> fantasai: also good for extensibility, especially if the fallback value can contain commas
859. # [16:00] * Bert considering other syntaxes... attr-url(src), attr-length(border, 0)...
860. # [16:00] <florian> howcome: this would break prince's implementation
861. # [16:01] <dbaron> howcome: put the type outside the parenthesis
862. # [16:01] <dbaron> Bert: should put the type in the function name (is that what howcome meant?)
863. # [16:02] <dbaron> Tab, Peter: would like to get some resolutions
864. # [16:02] <dbaron> Tab: can we resolved that exclusions, attr(), and the steps() function from transitions/animations can change?
865. # [16:03] <dbaron> dbaron: Gecko has implemented steps() since Firefox 5
866. # [16:03] <dbaron> smfr: I think WebKit would end up supporting both syntaxes for steps()
867. # [16:03] <dbaron> howcome: So you dropped the proposal to use 'as' as a keyword?
868. # [16:04] <dbaron> howcome: This would break target-counter() which has 2 implementations, which has href inside ...?...
869. # [16:04] <florian> howcome: we'd be breaking 2 implementatiosn
870. # [16:04] <dbaron> howcome: It's what you use to generate "see page 83"
871. # [16:04] * florian thanks dbaron for taking over scribing
872. # [16:05] <dbaron> howcome: They're not prefixed -- functions inside the content() property. Prince and antennahouse.
873. # [16:05] <dbaron> howcome: I think it's the same as the other argument that we're breaking implementations, so I would object to the change.
874. # [16:05] <dbaron> TabAtkins: previously when printing devices have implemented something unprefixed we've let them alias -- we care about the Web more than print implementations
875. # [16:06] <dbaron> howcome, ?: I disagree.
876. # [16:06] <dbaron> peterl: Over half of what comes out of HP printers is Web pages, mostly from browsers.
877. # [16:06] <dbaron> Peterl: We do care about offline renderers.
878. # [16:06] <dbaron> peterl: However, I'm fine with breaking people who shipped things unprefixed before they should have.
879. # [16:07] <dbaron> florian: We should still consider them before breaking them.
880. # [16:07] <dbaron> peterl: understod
881. # [16:08] <dbaron> peterl: Can't distinguish name,type,default from name,default,moredefault
882. # [16:08] * Joins: szilles (chatzilla@128.93.135.189)
883. # [16:08] <dbaron> howcome: ?
884. # [16:08] <dbaron> Tab: should just specify attr(href url)
885. # [16:09] <dbaron> TabAtkins: I think we should make this change.
886. # [16:09] <dbaron> peterl: ambiguous
887. # [16:09] <dbaron> TabAtkins: could say "if fallback value is the token 'url'" ... ?
888. # [16:09] <dbaron> howcome: We're not helping adaptation with implementors if we come in after 5 years and make arbitrary changes for little purpose.
889. # [16:10] <dbaron> Tantek: Why isn't the spec in CR?
890. # [16:10] <dbaron> howcome: lack of implementations
891. # [16:10] <dbaron> Tantek: then what's the problem?
892. # [16:10] <dbaron> howcome: non-browser implementations
893. # [16:11] <dbaron> howcome: values & units should be the last css3 spec out
894. # [16:11] <dbaron> dbaron: I think we all disagree with you on that
895. # [16:11] <dbaron> TabAtkins: exclusions, ignore the crazy rect()/rectangle() suggestion
896. # [16:11] <dbaron> TabAtkins: make changes for exclusions
897. # [16:11] <dbaron> TabAtkins: make changes for attr()
898. # [16:11] <dbaron> TabAtkins: maybe make changes for steps()
899. # [16:12] <dbaron> TabAtkins: for the rest, let things progress to CR and maybe make a compatible change in level 4
900. # [16:12] <dbaron> fantasai: if the concern is impls you could put it in the spec and mark it at risk
901. # [16:13] <dbaron> (We should do a third of them with ideographic commas to add to the mix. :-)
902. # [16:13] <dbaron> peterl: I'm happy with the proposed resolution but concern with the attr() thing
903. # [16:13] <dbaron> TabAtkins: I believe implementations could support both attr() without breaking
904. # [16:13] <dbaron> peterl: I think we should leave attr() for discussion
905. # [16:14] <dbaron> peterl: I think we should also resolve to accept the principles
906. # [16:14] <dbaron> peterl: And adapt them to old properties as we can and as it makes sense.
907. # [16:15] <dbaron> RESOLUTION: adopt the principles in http://wiki.csswg.org/ideas/functional-notation
908. # [16:15] <dbaron> RESOLUTION: adopt the proposed changes to exclusions in http://wiki.csswg.org/ideas/functional-notation except for the part on unifying rect() and rectangle()
909. # [16:16] <dbaron> ACTION Tab to investigate if we can change functional notation in steps() in line with http://wiki.csswg.org/ideas/functional-notation
910. # [16:16] * trackbot noticed an ACTION. Trying to create it.
911. # [16:16] <trackbot> Created ACTION-419 - Investigate if we can change functional notation in steps() in line with http://wiki.csswg.org/ideas/functional-notation [on Tab Atkins Jr. - due 2012-02-13].
912. # [16:16] <dbaron> ACTION Tab to work with howcome and AntennaHouse to see if we can change attr() as suggested in http://wiki.csswg.org/ideas/functional-notation
913. # [16:16] * trackbot noticed an ACTION. Trying to create it.
914. # [16:16] <trackbot> Created ACTION-420 - Work with howcome and AntennaHouse to see if we can change attr() as suggested in http://wiki.csswg.org/ideas/functional-notation [on Tab Atkins Jr. - due 2012-02-13].
915. # [16:16] * Quits: smfr (smfr@128.93.135.37) (Quit: smfr)
916. # [16:19] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
917. # [16:19] * Quits: Rossen (Rossen@128.93.134.228) (Ping timeout)
918. # [16:21] * Quits: tantek (tantek@128.93.135.20) (Quit: tantek)
919. # [16:24] * Quits: dbaron (dbaron@128.93.135.77) (Ping timeout)
920. # [16:25] * Joins: smfr (smfr@128.93.135.37)
921. # [16:28] * Joins: Rossen (Rossen@128.93.134.228)
922. # [16:31] * Quits: alexmog (alexmog@173.230.149.95) (Client exited)
923. # [16:31] * Quits: vhardy (vhardy@173.230.149.95) (Client exited)
924. # [16:31] * Quits: shans (shans@173.230.149.95) (Client exited)
925. # [16:31] * Quits: plinss (plinss@173.230.149.95) (Client exited)
926. # [16:31] * Quits: sylvaing (sylvaing@173.230.149.95) (Client exited)
927. # [16:32] * Joins: plinss (plinss@173.230.149.95)
928. # [16:33] * Joins: sylvaing_away (sylvaing@173.230.149.95)
929. # [16:34] * sylvaing_away is now known as sylvaing
930. # [16:34] * Joins: vhardy_away (vhardy@173.230.149.95)
931. # [16:34] * vhardy_away is now known as vhardy
932. # [16:35] * Joins: shans_away (shans@173.230.149.95)
933. # [16:35] * shans_away is now known as shans
934. # [16:36] * Joins: kojiishi (kojiishi@128.93.135.158)
935. # [16:38] <TabAtkins_> ScribeNick: TabAtkins_
936. # [16:38] * Joins: dbaron (dbaron@128.93.135.77)
937. # [16:39] * Joins: alexmog_away (alexmog@173.230.149.95)
938. # [16:39] <TabAtkins_> Topic: V&U Issues before LC
939. # [16:39] * alexmog_away is now known as alexmog
940. # [16:39] <TabAtkins_> TabAtkins_: fantasai and I hav eonly the one issue about attr()
941. # [16:39] * Joins: tantek (tantek@128.93.135.20)
942. # [16:39] <TabAtkins_> [no one else has any issues, apparently]
943. # [16:39] * Quits: sgalineau (sylvaing@128.93.135.76) (Quit: sgalineau)
944. # [16:39] <Bert> s/hav eonly/have only/
945. # [16:40] <TabAtkins_> plinss: Let's discuss the attr() issue now, see if we can resolve the legacy issues.
946. # [16:40] <fantasai> target-counter(href, ...) instead of target-counter(attr(href, url), ...)
947. # [16:42] <TabAtkins_> plinss: Anyone object to going to LC after the attr() issue?
948. # [16:42] <fantasai> ACTION fantasai: Add example of background-position with calc()
949. # [16:42] * trackbot noticed an ACTION. Trying to create it.
950. # [16:42] * RRSAgent records action 1
951. # [16:42] <trackbot> Created ACTION-421 - Add example of background-position with calc() [on Elika Etemad - due 2012-02-13].
952. # [16:42] <TabAtkins_> sylvaing: I think there was an issue about calc() and background-position.
953. # [16:42] <TabAtkins_> TabAtkins_: Elika pointed out that if you lawyer the spec correctly, it's not a problem at all.
954. # [16:43] <TabAtkins_> fantasai: I can add an example with an explanation.
955. # [16:43] <TabAtkins_> plinss: We'll come back to attr() on next telcon.
956. # [16:43] <TabAtkins_> Topic: Regions scope
957. # [16:43] <dbaron> I'm not crazy about the intro to css3-values section 8 (functional notations) using url() as an example of a function
958. # [16:43] <TabAtkins_> vhardy: There's been feedback on region scope.
959. # [16:43] <dbaron> given how special url() is
960. # [16:44] <TabAtkins_> vhardy: On our end we'd like to present our working assumptions.
961. # [16:44] <TabAtkins_> vhardy: And, per a request from Hakon, what we think the bigger picture is and how that would work in the larger group.
962. # [16:44] <TabAtkins_> vhardy: So, to recap would take about 20 minutes.
963. # [16:45] <TabAtkins_> Rossen: [shows some slides]
964. # [16:45] <TabAtkins_> Rossen: [recaps CSS regions]
965. # [16:46] * Joins: vhardy_ (qw3birc@128.30.52.28)
966. # [16:46] <TabAtkins_> Rossen: An Element that is able to receive and output content from other elements is a Named Flow.
967. # [16:47] <TabAtkins_> Rossen: Fragmenter - boxes produced by a region can fragment their content.
968. # [16:48] <TabAtkins_> fantasai: Page boxes, column boxes, regions are all fragmenters.
969. # [16:48] <TabAtkins_> Rossen: In regions it can be controlled with 'region-break'
970. # [16:49] * Joins: ChrisL (ChrisL@128.30.52.169)
971. # [16:49] <TabAtkins_> Rossen: [shows the canon region example, highlighting the boxes containing text]
972. # [16:49] * ChrisL is awake and mostly better
973. # [16:49] <ChrisL> rrsagent, here
974. # [16:49] <RRSAgent> See http://www.w3.org/2012/02/06-css-irc#T15-42-12
975. # [16:49] * TabAtkins_ ChrisL, huzzah!
976. # [16:49] <ChrisL> rrsagent, make logs public
977. # [16:49] <RRSAgent> I have made the request, ChrisL
978. # [16:49] <TabAtkins_> Rossen: There is region styling on the first region, changing the font-size.
979. # [16:50] <TabAtkins_> Rossen: Out of scope of regions is the breaking rules - specified in CSS3 Fragmentation.
980. # [16:50] <TabAtkins_> Rossen: That spec should cover *all* breaking rules - pages, columns, regions, and future stuff.
981. # [16:50] <TabAtkins_> Rossen: Finally, out-of-scope is auto-generation, conditional-generation, or grouping of regions. This should be covered by a Page Templates module.
982. # [16:51] <TabAtkins_> florian: Defining them in a separate document seems fine to me, as long as we do it simultaneously and know aproximately what we're doing.
983. # [16:52] <TabAtkins_> Bert: When you say Fragmention, is that a new name for Paged Media?
984. # [16:53] <TabAtkins_> fantasai: No, new spec. This is specifically about breaking. Paged Media is now just about the page boxes themselves.
985. # [16:53] <TabAtkins_> Bert: So the break properties, and widows and orphans. Anything more?
986. # [16:53] <TabAtkins_> Rossen: Some text about variable-width containers, etc., but that's about it.
987. # [16:53] <TabAtkins_> vhardy: [shows some different slides]
988. # [16:54] <TabAtkins_> vhardy: Here's context about why we brought them to the group.
989. # [16:54] <TabAtkins_> vhardy: There were two features we couldnt script our way around.
990. # [16:55] <TabAtkins_> vhardy: Our people tried to have multiple aspect ratios, and multiple form factors.
991. # [16:55] <TabAtkins_> vhardy: [shows a slide of a fairly large screen with three columns of text, some pull-quotes]
992. # [16:56] <TabAtkins_> vhardy: In this example, the content uses three templates.
993. # [16:56] * glazou notes : don't forget to invite rrsagent BEFORE start of meeting for logs
994. # [16:57] <TabAtkins_> vhardy: But on smaller content, you have substantially different templates.
995. # [16:57] <TabAtkins_> s/content/screens/
996. # [16:58] <TabAtkins_> vhardy: There's also justification for page templates being conditional - based on the content, you may use different templtaes.
997. # [16:59] * Joins: smfr_ (smfr@128.93.135.37)
998. # [16:59] <TabAtkins_> vhardy: The regions offers the way of pulling content into the template.
999. # [16:59] * Quits: smfr (smfr@128.93.135.37) (Connection reset by peer)
1000. # [16:59] * smfr_ is now known as smfr
1001. # [17:00] <TabAtkins_> vhardy: So one approach that could work here is GCPM - use paged overflow and media queries to swap out templates.
1002. # [17:00] <TabAtkins_> vhardy: The @page rule would contain a template and specify how areas of the template are regions.
1003. # [17:01] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
1004. # [17:01] <TabAtkins_> vhardy: In our experience, trying to do magazine content, there's reason to do conditional content.
1005. # [17:01] <TabAtkins_> vhardy: For exapmle, if a page's content has a pull-quote region, use the templtae meant for pull-quotes.
1006. # [17:02] <TabAtkins_> vhardy: Further, one can leverage regions and pseudo-elements to control the flowing in th epage templates.
1007. # [17:03] <TabAtkins_> vhardy: So the core notion is that you would use CSS (@page and pseudos) to define the templates, and use regions to pull content into them.
1008. # [17:03] <TabAtkins_> vhardy: This is important, because the people asking us for these abilities want very precise control over how things are laid out.
1009. # [17:04] <TabAtkins_> szilles: The WebApps group is also looking at templates in this context, and there's an opportunity for discussion.
1010. # [17:04] <TabAtkins_> szilles: HTML-based templates, shadow DOM, etc.
1011. # [17:05] <TabAtkins_> Bert: Two comments.
1012. # [17:05] <TabAtkins_> Bert: Regarding ::slot(), I had resolved to put it directly after the @page token. This avoids mixing with @page styles, and also makes it look more like a selector.
1013. # [17:06] <TabAtkins_> Bert: The other comment is looking at the "nth(2)", and wondering if this is what we wanted.
1014. # [17:06] <TabAtkins_> Bert: I thought we had ideas about named pages.
1015. # [17:07] <TabAtkins_> Bert: Another comment, XSL already has things like this.
1016. # [17:07] <TabAtkins_> Bert: We should probably look at what they've done already.
1017. # [17:07] <TabAtkins_> szilles: I think the main thing is what vincent already hinted at - conditional choice pages.
1018. # [17:07] * Quits: tantek (tantek@128.93.135.20) (Ping timeout)
1019. # [17:07] <TabAtkins_> szilles: His example of small and large templates was primitive, but obviously useful.
1020. # [17:08] <TabAtkins_> szilles: The XSL mechanism had extremely primitive questions you could ask.
1021. # [17:08] <TabAtkins_> szilles: But in general you want to be able to see if the next page's content contains images, particular flows, etc., and select your template based on that.
1022. # [17:09] <TabAtkins_> szilles: We don't need to get into specifics now, but the notion of conditioning based on content is important.
1023. # [17:10] <TabAtkins_> vhardy: [shows some demos]
1024. # [17:11] <TabAtkins_> vhardy: [first demo shows regions being created/destroyed dynamically based on the length of the content]
1025. # [17:11] <TabAtkins_> vhardy: It uses the regions OM to tell when there is overflow/underflow so it can create/destroy "columns" and "pages" with script.
1026. # [17:11] <TabAtkins_> vhardy: If we could do all this declaratively, it would be great.
1027. # [17:12] * Joins: tantek (tantek@128.93.135.20)
1028. # [17:13] <TabAtkins_> vhardy: [shows another demo]
1029. # [17:13] <TabAtkins_> florian: I think this demo can be done with overflow:paged, too.
1030. # [17:15] <glazou> jdaggett, dbaron, florian, vhardy : 119 people registered for wednesday evening at La Cantine
1031. # [17:15] <TabAtkins_> howcome: [shows a similar demo using display:table and multicol to achieve a result similar to the english/french stuff.
1032. # [17:15] <jdaggett> glazou: wow!
1033. # [17:15] * Quits: vhardy_ (qw3birc@128.30.52.28) (Ping timeout)
1034. # [17:16] <TabAtkins_> astearns: In the template example, different pages were split in different ways. That seems incompatible.
1035. # [17:16] <jdaggett> glazou: will there be enough air in the room?
1036. # [17:16] <TabAtkins_> howcome: There may be changes needed, yes.
1037. # [17:16] <TabAtkins_> howcome: I think if we can just agree on the general shape of CSS syntax for making region targets is good, so we don't need to have dummy elements.
1038. # [17:18] <TabAtkins_> vhardy: We found that often you need to nest the containers needed for complex but realistic layouts. That makes it hard to work with pseudos.
1039. # [17:18] <TabAtkins_> glazou: [talks about HTML-to-CSS templates]
1040. # [17:18] <TabAtkins_> Bert: I think you are putting up a hack as a solution.
1041. # [17:18] <TabAtkins_> glazou: I think they're using it because it's simple.
1042. # [17:19] <TabAtkins_> fantasai: People are using those for actual HTML templates - that's the markup they want.
1043. # [17:20] <TabAtkins_> howcome: There's a finite number of elements in the page. You still are forced to use JS to create new elements as necessary.
1044. # [17:20] <TabAtkins_> astearns: The idea is that regions are primitives. They could be elements or pseudo-elements or what-have-you.
1045. # [17:20] <TabAtkins_> astearns: We don't want to limit what Regions can be.
1046. # [17:21] <TabAtkins_> astearns: We just want these primitive region concepts that can be used *now* with JS, and *soon* with page templates, etc.
1047. # [17:21] <TabAtkins_> howcome: If a property can only be used in practice with JS, I think that's wrong. CSS has always been able to create boxes as we need them.
1048. # [17:22] <TabAtkins_> vhardy: I think it would be great to have slots and such.
1049. # [17:22] <TabAtkins_> vhardy: We tried to push it far in the earlier proposals, but it got *ugly*.
1050. # [17:23] <TabAtkins_> vhardy: For simple things, using ::slot() or similar with regions is great. For more complex things like Wired Magazine, HTML seems very good for setting this.
1051. # [17:24] * Joins: alexmog_ (qw3birc@128.30.52.28)
1052. # [17:24] <TabAtkins_> vhardy: the way we script things currently is that we have a custom CSS syntax, and we parse that and then generate things in the DOM based on that.
1053. # [17:24] <TabAtkins_> vhardy: If we had shadow DOM, or some way to use boxes without elements, we'd use that.
1054. # [17:25] <TabAtkins_> florian: For all the examples you have, the most tricky ones may be complicated, but everything else is doable with existing stuff.
1055. # [17:26] <TabAtkins_> alexmog_: The purpose of this was just to introduce our ideas. We'll have future conversations about how to address templates and such.
1056. # [17:26] * dbaron can't follow this discussion at all
1057. # [17:26] * TabAtkins_ neither.
1058. # [17:27] <TabAtkins_> alexmog_: [some discussion I missed]
1059. # [17:27] <TabAtkins_> florian: It seems to me that if you have a different solution, you'll always find some cases that you nee dyour solution for.
1060. # [17:28] <dbaron> s/nee dyour/need your/
1061. # [17:28] <TabAtkins_> florian: But it seems that in *most* cases, you can solve them with simpler things.
1062. # [17:29] <fantasai> dbaron: AFAICT, you went through a presentation very quickly, not giving ppl a chance to comment, and now saying we have to move on without asking questions.
1063. # [17:30] <TabAtkins_> alexmog_: I'm trying to separate these conversations because...
1064. # [17:30] <TabAtkins_> dbaron: What convos are you trying to separate?
1065. # [17:30] <TabAtkins_> alexmog_: I want to delay discussions on use-cases and solutions until a longer solution with Hakon about what is happening.
1066. # [17:30] <TabAtkins_> alexmog_: I would be happy to analyze specific use-cases now if we have time, to show that only Regions can solve those.
1067. # [17:31] <TabAtkins_> alexmog_: I think that preparing for that would be more productive with a small session first.
1068. # [17:31] <TabAtkins_> alexmog_: These use-cases are posted in the wiki.
1069. # [17:32] <tantek> URL?
1070. # [17:32] <Rossen> http://wiki.csswg.org/spec/page-view
1071. # [17:32] <TabAtkins_> vhardy: We are trying to make progress on Regions, and what the spec covers or not is in question.
1072. # [17:32] <astearns> http://wiki.csswg.org/spec/css3-region-templates
1073. # [17:32] <TabAtkins_> vhardy: So we need to see if we can address things like auto-height, tiling, etc., or if we need to go back further in the idea.
1074. # [17:32] <TabAtkins_> dbaron: Okay, I heard that, and then it delved into very specific examples, and it wasn't clear how they connected.
1075. # [17:33] <TabAtkins_> vhardy: One of the big questions that hakon has asked is how you generate regions, how you paginate, etc., and so I tried to show that.
1076. # [17:34] <TabAtkins_> sylvaing: At TPAC we said that certain things are out-of-scope of regions, and so the presentation showed that those out-of-scope things are needed for some of the questions being raised.
1077. # [17:35] <Bert> (So I think Regions is about: (1) given that there are regions on the canvas (created with a grid template or in some other way), we need a way to chain them together so content flows from one to the next; (2) given that there are regions, we want to assign style to them that overrides the style set on the elements whose content ends up in those regions.)
1078. # [17:35] <TabAtkins_> howcome: but you need the page templates for evaluating regions.
1079. # [17:36] <TabAtkins_> astearns: My take is that there are problems you can poke at with our examples, and with GCPM, but there's a need for both to have a primitive thing to flow content through.
1080. # [17:36] <TabAtkins_> astearns: In multicol it's a column element. Regions are a further abstraction - it's not a multicol, it's bare columns that can be put anywhere.
1081. # [17:37] <TabAtkins_> astearns: It's the multicol layout scheme that isn't generic enough, so we needed to go further down and have simple, primitive flow-through boxes.
1082. # [17:37] <TabAtkins_> howcome: In doing so, you lose the fundamental scalability of the web.
1083. # [17:37] <TabAtkins_> howcome: Look at this example (the canon regions example).
1084. # [17:38] <TabAtkins_> howcome: If the screen gets wider, you can't add another column to the right.
1085. # [17:38] <TabAtkins_> Rossen: This is what page templates are going toward.
1086. # [17:38] <TabAtkins_> howcome: But we haven't seen them! We can't evaluate a non-existing spec.
1087. # [17:39] <TabAtkins_> alexmog_: First, we'd like to work with you for a complete solution.
1088. # [17:39] <TabAtkins_> alexmog_: Second, regions as they are are following the same pattern as everything else in CSS.
1089. # [17:39] <TabAtkins_> alexmog_: Following existing typography tradition being described in a language.
1090. # [17:40] <TabAtkins_> howcome: Right now we have multiple plans, and I think we should talk about just the declarative stuff right now.
1091. # [17:41] <TabAtkins_> szilles: If you want declarative, why do you have an OM?
1092. # [17:41] <TabAtkins_> howcome: It allows more functionality. But it's not required to display things.
1093. # [17:41] <TabAtkins_> howcome: What I fear is that IE will ipmlement the script-centric approach and nothing else.
1094. # [17:42] <TabAtkins_> alexmog_: What you are suggesting does not yet address all the use-cases we've presented.
1095. # [17:42] <TabAtkins_> howcome: I've been away for a bit, but I've answered many of them.
1096. # [17:43] <TabAtkins_> howcome: Number one example of an exclusion is a pullquote that comes out of some text and goes between two columns.
1097. # [17:43] <TabAtkins_> howcome: It can't be done in your approach.
1098. # [17:43] * Joins: arno (arno@192.150.10.200)
1099. # [17:44] <fantasai> Tab: What is the point of this discussion? I don't want to minute random meanderings.
1100. # [17:44] <TabAtkins_> florian: The problem I see is that we're introducing various pieces that are meant to be combined, but we're not considering them together.
1101. # [17:44] * Joins: arron (Arron@24.17.123.244)
1102. # [17:44] <TabAtkins_> florian: As long as we discuss them separately, we aren't dealing with it.
1103. # [17:45] <TabAtkins_> alexmog_: We know we disagree somewhat. Can we move past that?
1104. # [17:45] <TabAtkins_> howcome: We could if we agreed on the declarative approach.
1105. # [17:45] <TabAtkins_> vhardy: On your end, hakon, you take existing content and figure out how to paginate on multiple devices, as automated as possible, with as little knowledge as possible.
1106. # [17:46] <TabAtkins_> vhardy: Where we're coming from is different - design houses that want precise control over content when it's paginated.
1107. # [17:48] <TabAtkins_> TabAtkins_: Within the context of epub, we explicitly rejected the "precise design" use-case as a thing for CSS to worry about. Why are we worrying about that in the context of Regions?
1108. # [17:49] <TabAtkins_> szilles: Not precise control, but a design that will scale over a reasonable set of form factors, combined with media queries.
1109. # [17:49] <TabAtkins_> florian: I agree, but I don't see how you go from there to "you need this type of regions"
1110. # [17:50] <TabAtkins_> szilles: Some people believe that there aren't reasonable ways to use columns.
1111. # [17:50] <TabAtkins_> florian: Using current columns, yes.
1112. # [17:50] <TabAtkins_> szilles: I see columns as combining two things. They do columns, and they do auto-generation.
1113. # [17:50] * Joins: kojiishi (kojiishi@128.93.135.158)
1114. # [17:50] <TabAtkins_> szilles: I think it's more powerful to separate those two things into building blocks.
1115. # [17:50] <TabAtkins_> szilles: And use things like conditional page templates for auto-generation.
1116. # [17:51] <TabAtkins_> howcome: That' s afine approach, but it doesn't need script.
1117. # [17:51] <TabAtkins_> szilles: I don't think we know the set of templates or rules that we'll need yet.
1118. # [17:51] <TabAtkins_> vhardy: Multicol gives us a lot of the abilities we need, but with a single, particular layout solution, when we have use-cases for lots of different layouts.
1119. # [17:52] <TabAtkins_> vhardy: If the last region is always overflow/auto-scroll/etc, there will always be a way to show the additional content.
1120. # [17:52] <TabAtkins_> howcome: How does the content get onto the next page?
1121. # [17:53] <TabAtkins_> alexmog_: How it gets onto the next page is the next thing we need to write.
1122. # [17:53] <TabAtkins_> florian: That's what we can't accept!
1123. # [17:53] <TabAtkins_> fantasai: You need script to do something like fancy regions on page 1, and then just simple columns on the rest.
1124. # [17:53] <TabAtkins_> vhardy: There are different problems and concerns.
1125. # [17:54] <TabAtkins_> vhardy: Regions is trying to be agnostic about the boxes it's flowing into. Anything that can take 'flow-from' is a region container.
1126. # [17:54] <TabAtkins_> florian: The least-effort way of doing things doesn't get you what you want.
1127. # [17:55] <TabAtkins_> macpherson: You *could* generate the rest with JS, or have it do automatically with columns.
1128. # [17:55] <TabAtkins_> fantasai: Solutions like putting a bunch of extra <div>s that may or may not work isn't a good solution.
1129. # [17:55] <TabAtkins_> macpherson: One problem is that we currently don't have good multicol integration.
1130. # [17:55] <TabAtkins_> macpherson: But CSS already doesn't solve this case.
1131. # [17:56] * glazou recommends leaving the implementors having a flow layout proposal on the table in one room, locking it, letting only one survivor leave
1132. # [17:56] <TabAtkins_> fantasai: What we're saying is that the cases that are easy to solve in CSS is still hard in Regions.
1133. # [17:56] <TabAtkins_> fantasai: We're seeing part of a solution and being assured that the rest will come eventually, but right now the piece we know isn't capable of doing robust layout.
1134. # [17:56] <TabAtkins_> vhardy: But regions aren't layout.
1135. # [17:57] <TabAtkins_> fantasai: Agreed. But based on what we have right now, Regions makes it possible to create very *non-robust* layouts.
1136. # [17:57] <TabAtkins_> howcome: If there's one thing we've learned, scripting isn't robust.
1137. # [17:57] <TabAtkins_> macpherson: What's the problem with having the last thing be auto-sized?
1138. # [17:57] <TabAtkins_> howcome: If that's the approach, I'm happy. I just don't like the script-centric thing.
1139. # [17:58] * glazou thinks we urgently need two other bottles of wine for Håkon
1140. # [17:59] <TabAtkins_> sylvaing: without dom elements, you can't receive clicks, etc.
1141. # [18:00] * arron glazou: imagine if you are following this only on IRC. I really need a bottle of wine.
1142. # [18:00] <TabAtkins_> antonp: The problem right now is that, based on what we have right now, it seems that scripts are required.
1143. # [18:00] <glazou> arron: LOL
1144. # [18:00] * ChrisL does not have to imagine following only on IRC
1145. # [18:00] * fantasai thinks anton didn't get minuted quite right
1146. # [18:00] * fantasai pokes antonp
1147. # [18:01] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
1148. # [18:01] <TabAtkins_> antonp: Is the objection about a theoretical problem with regions right now, or practical issues?
1149. # [18:01] <TabAtkins_> astearns: I think finding a good, complete solution can only be furthered by having the primitives right now, even if scripts are needed to use them *right now*.
1150. # [18:02] <TabAtkins_> astearns: So get a set of functionality in place, and then extend it.
1151. # [18:02] <TabAtkins_> florian: It seems that in the future we're pointing at the same needs. But what you proposed is that, on day 1, you can use tools to create great stuff on the kindle, but not on the web. We're wanting to make sure that it scales better across the web/devices on day 1 as well.
1152. # [18:03] <TabAtkins_> florian: Our ideas don't support quite as fancy stuff as yours on day 1, but they do handle better scaling on day 1.
1153. # [18:03] <TabAtkins_> vhardy: We have a solution today which is fully scripted.
1154. # [18:03] <TabAtkins_> vhardy: We feel that this isn't a good solution.
1155. # [18:03] <TabAtkins_> vhardy: Even without regions.
1156. # [18:03] <TabAtkins_> vhardy: If we don't do this, we'll stick with fully-scripted.
1157. # [18:03] * glazou BTW, we miss you here arron
1158. # [18:04] <TabAtkins_> vhardy: [shows example with the last region taking the rest of the content and scrolling]
1159. # [18:04] * arron glazou: I wish I was there. Could you post the agenda for me? I missed the link earlier.
1160. # [18:05] <TabAtkins_> vhardy: If we had th elast region be auto-height, it wouldn't need to be scrolled. It could be multicol.
1161. # [18:05] <TabAtkins_> howcome: It doesn't work today?
1162. # [18:05] * fantasai arron, http://wiki.csswg.org/planning/paris-2012
1163. # [18:05] <TabAtkins_> vhardy: Not per spec.
1164. # [18:05] <glazou> arron: we have so much on the list of proposals that we establish it on the fly every day
1165. # [18:05] * fantasai we still haven't figured out Tues/Thurs
1166. # [18:05] <glazou> arron: we won't be able to do everything in 3 days
1167. # [18:06] <glazou> arron, ChrisL : we adjourn in 2 mins
1168. # [18:06] <ChrisL> thanks. mostly caught up by IRC logs now.
1169. # [18:06] <glazou> cool
1170. # [18:06] <arron> glazou: that doesn't shock me too much. we are getting more issues
1171. # [18:06] <TabAtkins_> Bert: The assumption of regions is that the spec is a way to make regions, and then you can style/position them later.
1172. # [18:06] * Joins: kojiishi (kojiishi@128.93.135.158)
1173. # [18:07] <TabAtkins_> Bert: I'm predicting that once we know how to make regions, we'll know how to do these things, and they'll fall out.
1174. # [18:07] * fantasai agrees with Bert
1175. # [18:07] <TabAtkins_> vhardy: I think that the automatic generation of boxes is useful, but not just for regions. It can be used for more things.
1176. # [18:08] <fantasai> Tab: Afaict, layouts should only need Grid. What's missing?
1177. # [18:09] <Bert> s/that the spec/that somewhere else there/
1178. # [18:09] <glazou> ADJOURN
1179. # [18:10] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
1180. # [18:10] * Quits: smfr (smfr@128.93.135.37) (Quit: smfr)
1181. # [18:10] * Quits: jdaggett (jdaggett@128.93.134.208) (Quit: jdaggett)
1182. # [18:10] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
1183. # [18:10] * plinss is now known as plinss_away
1184. # [18:11] * Quits: florian (florianr@128.93.135.13) (Ping timeout)
1185. # [18:11] * Quits: jet (jet@128.93.134.212) (Quit: jet)
1186. # [18:12] * Quits: dbaron (dbaron@128.93.135.77) (Quit: 8403864 bytes have been tenured, next gc will be global.)
1187. # [18:13] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
1188. # [18:13] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
1189. # [18:13] * Quits: Rossen (Rossen@128.93.134.228) (Ping timeout)
1190. # [18:13] * Quits: TabAtkins_ (tabatkins@74.125.122.49) (Ping timeout)
1191. # [18:15] * Quits: tantek (tantek@128.93.135.20) (Quit: tantek)
1192. # [18:16] * Quits: antonp (805d86d1@78.129.202.38) (Quit: http://www.mibbit.com ajax IRC Client)
1193. # [18:17] * Quits: astearns (qw3birc@128.30.52.28) (Ping timeout)
1194. # [18:17] * sylvaing is now known as sylvaing_away
1195. # [18:19] * Quits: howcome (howcome@128.93.135.53) (Ping timeout)
1196. # [18:20] * Quits: szilles (chatzilla@128.93.135.189) (Ping timeout)
1197. # [18:45] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
1198. # [18:52] * Joins: kojiishi (kojiishi@92.151.219.3)
1199. # [18:55] * Joins: TabAtkins_ (tabatkins@92.151.219.3)
1200. # [19:00] * sylvaing_away is now known as sylvaing
1201. # [19:04] * plinss_away is now known as plinss
1202. # [19:12] * Joins: tantek (tantek@92.151.219.3)
1203. # [19:13] * Joins: TabAtkin1_ (tabatkins@90.46.85.61)
1204. # [19:14] * Joins: kojiishi_ (kojiishi@90.46.85.61)
1205. # [19:14] * Joins: tantek_ (tantek@90.46.85.61)
1206. # [19:15] * Quits: tantek (tantek@92.151.219.3) (Ping timeout)
1207. # [19:15] * tantek_ is now known as tantek
1208. # [19:15] * Quits: kojiishi (kojiishi@92.151.219.3) (Ping timeout)
1209. # [19:15] * Quits: TabAtkins_ (tabatkins@92.151.219.3) (Ping timeout)
1210. # [19:20] * Quits: Ms2ger (Ms2ger@94.226.67.71) (Ping timeout)
1211. # [19:54] * Quits: TabAtkin1_ (tabatkins@90.46.85.61) (Ping timeout)
1212. # [19:56] * Quits: tantek (tantek@90.46.85.61) (Quit: tantek)
1213. # [19:56] * Quits: kojiishi_ (kojiishi@90.46.85.61) (Ping timeout)
1214. # [20:08] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
1215. # [20:10] * Joins: arno (arno@192.150.10.200)
1216. # [20:11] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
1217. # [20:11] * Joins: arno (arno@192.150.10.200)
1218. # [20:18] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
1219. # [20:28] * Joins: arno (arno@192.150.10.200)
1220. # [20:32] * plinss is now known as plinss_away
1221. # [20:36] * Joins: arronei_ (arronei@131.107.0.112)
1222. # [20:37] * Quits: arronei (arronei@131.107.0.89) (Ping timeout)
1223. # [20:44] * Quits: karl (karlcow@128.30.54.58) (Quit: :tiuQ tiuq sah woclrak)
1224. # [20:58] * sylvaing is now known as sylvaing_away
1225. # [21:06] * Joins: jdaggett (jdaggett@81.56.65.178)
1226. # [21:10] * Joins: jdaggett_ (jdaggett@81.56.65.178)
1227. # [21:10] * Quits: jdaggett (jdaggett@81.56.65.178) (Connection reset by peer)
1228. # [21:10] * jdaggett_ is now known as jdaggett
1229. # [21:12] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
1230. # [21:12] * Quits: jdaggett (jdaggett@81.56.65.178) (Connection reset by peer)
1231. # [21:12] * Joins: jdaggett (jdaggett@81.56.65.178)
1232. # [21:16] * Joins: arno (arno@192.150.10.200)
1233. # [21:21] * Joins: glenn (gadams@192.160.73.179)
1234. # [21:22] * Joins: Ms2ger (Ms2ger@94.224.25.87)
1235. # [21:23] * Quits: jdaggett (jdaggett@81.56.65.178) (Quit: jdaggett)
1236. # [21:23] * Joins: jdaggett (jdaggett@81.56.65.178)
1237. # [21:33] * Quits: Ms2ger (Ms2ger@94.224.25.87) (Ping timeout)
1238. # [21:36] * Joins: Ms2ger (Ms2ger@94.224.25.87)
1239. # [21:57] * Joins: tantek (tantek@90.46.85.61)
1240. # [22:00] * Joins: TabAtkins_ (tabatkins@90.46.85.61)
1241. # [22:05] * Joins: jarek (jarek@79.186.11.73)
1242. # [22:13] * plinss_away is now known as plinss
1243. # [22:19] * Quits: jarek (jarek@79.186.11.73) (Quit: jarek)
1244. # [22:31] * Quits: tantek (tantek@90.46.85.61) (Quit: tantek)
1245. # [22:35] * Quits: Ms2ger (Ms2ger@94.224.25.87) (Quit: nn)
1246. # [22:43] * Joins: Rossen (Rossen@82.66.216.139)
1247. # [22:44] * Joins: kojiishi (kojiishi@90.46.85.61)
1248. # [22:58] * Joins: tantek (tantek@90.46.85.61)
1249. # [23:17] * Quits: Rossen (Rossen@82.66.216.139) (Quit: Rossen)
1250. # [23:44] * Quits: glenn (gadams@192.160.73.179) (Client exited)
1251. # Session Close: Tue Feb 07 00:00:00 2012

The end :)