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

Options:

  1. # Session Start: Wed Feb 08 00:00:00 2012
  2. # Session Ident: #css
  3. # [00:13] * Joins: karl (karlcow@128.30.54.58)
  4. # [00:13] * Joins: leaverou (leaverou@141.255.103.17)
  5. # [00:19] * plinss is now known as plinss_away
  6. # [00:21] * plinss_away is now known as plinss
  7. # [00:22] * Joins: ksweeney (ksweeney@63.119.10.10)
  8. # [00:23] * Quits: ksweeney (ksweeney@63.119.10.10) (Quit: Leaving.)
  9. # [00:23] * Joins: ksweeney (ksweeney@63.119.10.10)
  10. # [00:23] * Quits: ksweeney (ksweeney@63.119.10.10) (Quit: Leaving.)
  11. # [00:38] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  12. # [00:39] * Joins: arno (arno@192.150.10.200)
  13. # [00:42] * Quits: drublic (drublic@77.2.136.131) (Client exited)
  14. # [00:43] * Quits: TabAtkins_ (tabatkins@90.46.85.61) (Ping timeout)
  15. # [00:43] * sylvaing_away is now known as sylvaing
  16. # [00:44] * Joins: Rossen (Rossen@82.66.216.139)
  17. # [01:06] * plinss is now known as plinss_away
  18. # [01:21] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  19. # [01:30] * Joins: arno (arno@192.150.10.200)
  20. # [01:37] * sylvaing is now known as sylvaing_away
  21. # [01:39] * Quits: glenn (gadams@192.160.73.102) (Client exited)
  22. # [01:52] * Quits: Rossen (Rossen@82.66.216.139) (Ping timeout)
  23. # [01:52] * Joins: Rossen (Rossen@82.66.216.139)
  24. # [01:55] * Quits: arronei (arronei@131.107.0.118) (Quit: arronei)
  25. # [02:12] * Joins: miketaylr (miketaylr@187.105.255.109)
  26. # [02:20] * Joins: arronei (arronei@131.107.0.117)
  27. # [02:31] * Quits: Rossen (Rossen@82.66.216.139) (Ping timeout)
  28. # [03:50] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  29. # [04:29] * Quits: miketaylr (miketaylr@187.105.255.109) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
  30. # [05:41] * RRSAgent excuses himself; his presence no longer seems to be needed
  31. # [05:41] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
  32. # [06:25] * Joins: glenn (gadams@174.29.108.15)
  33. # [06:51] * Quits: nimbu (Adium@24.18.47.160) (Quit: Leaving.)
  34. # [06:59] * Joins: tantek (tantek@90.46.85.61)
  35. # [07:38] * plinss_away is now known as plinss
  36. # [07:56] * sylvaing_away is now known as sylvaing
  37. # [08:04] * Joins: TabAtkins_ (tabatkins@90.46.85.61)
  38. # [08:20] * Quits: glenn (gadams@174.29.108.15) (Client exited)
  39. # [08:32] * Quits: tantek (tantek@90.46.85.61) (Quit: tantek)
  40. # [08:32] * plinss is now known as plinss_away
  41. # [08:34] * sylvaing is now known as sylvaing_away
  42. # [08:46] * plinss_away is now known as plinss
  43. # [08:47] * Quits: TabAtkins_ (tabatkins@90.46.85.61) (Ping timeout)
  44. # [09:05] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  45. # [09:05] <RRSAgent> logging to http://www.w3.org/2012/02/08-css-irc
  46. # [09:10] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  47. # [09:12] * Joins: Rossen (Rossen@128.93.134.230)
  48. # [09:12] * Joins: glazou (glazou@128.93.135.193)
  49. # [09:12] * Joins: glenn (gadams@174.29.108.15)
  50. # [09:15] * Joins: florian (florianr@128.93.135.105)
  51. # [09:16] * Joins: smfr (smfr@128.93.135.224)
  52. # [09:19] * sylvaing_away is now known as sylvaing
  53. # [09:20] * Joins: jdaggett (jdaggett@128.93.134.228)
  54. # [09:22] * Joins: astearns (qw3birc@128.30.52.28)
  55. # [09:22] <fantasai> Topic: Dropping Prefixes
  56. # [09:22] <fantasai> ScribeNick: fantasai
  57. # [09:23] <fantasai> plinss: How long do you want?
  58. # [09:23] <fantasai> fantasai: 15 min
  59. # [09:23] * Joins: dbaron (dbaron@128.93.135.77)
  60. # [09:23] * Joins: vhardy_ (qw3birc@128.30.52.28)
  61. # [09:23] <fantasai> Tab: Proposal is transforms, animations, transitions syntaxis fully stable.
  62. # [09:24] <fantasai> Tab: So although the spec has some issues for CR, we propose to drop prefixes
  63. # [09:24] <fantasai> smfr: 2D or 3D transforms?
  64. # [09:24] <fantasai> Tab: Don't know
  65. # [09:24] <fantasai> glazou: What makes you think they're stable?
  66. # [09:24] <fantasai> Tab: Syntax hasn't changed in years
  67. # [09:25] <dbaron> ?: but you just proposed changing functional notation
  68. # [09:25] <fantasai> glazou: What about commas in functions?
  69. # [09:25] <fantasai> Tab: We'd have to preserve back-compat anyway
  70. # [09:25] <fantasai> Steve: Let's discuss on mailing list
  71. # [09:26] <fantasai> glazou: I think I agree with you in general
  72. # [09:26] <vhardy_> q+
  73. # [09:26] * Zakim sees vhardy_ on the speaker queue
  74. # [09:26] <fantasai> glazou: I want to make sure we don't have clockwise/counter-clockwise disagreement in the implementations
  75. # [09:26] <fantasai> dbaron: That's a 3D issues, and we changed the spec to match implementations
  76. # [09:26] <fantasai> glazou: I want to make sure we don't get exactly opposite results in 2 different browsers
  77. # [09:26] <plinss> ack vhardy
  78. # [09:26] * Zakim sees no one on the speaker queue
  79. # [09:27] <fantasai> Vincent: Shulz has raised parsing issues wrt transforms, we need to discuss to finalize that
  80. # [09:27] <smfr> http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#Differences_between_SVG_Transforms_and_CSS_Transforms
  81. # [09:27] <fantasai> dbaron: I think it's 3 years too late for that
  82. # [09:27] <fantasai> fantasai: The proposal is to list these under the legacy clause of the 2012 snapshot.
  83. # [09:28] <fantasai> fantasai: These are the top things on the pressure-to-implement-webkit-prefixes list
  84. # [09:28] <dbaron> smfr: Listing these three as exceptions seems wrong; the right thing seems to be accelerate the spec to CR.
  85. # [09:28] * Quits: glenn (gadams@174.29.108.15) (Client exited)
  86. # [09:28] <fantasai> smfr: Does dropping the prefixes let us fix the spec problems?
  87. # [09:28] <fantasai> smfr: I would prefer to accelerate the spec to CR than to drop the prefixes first.
  88. # [09:29] * Joins: arron (Arron@24.17.123.244)
  89. # [09:29] * Joins: TabAtkins_ (tabatkins@74.125.122.49)
  90. # [09:29] <fantasai> Tab: We want to make sure this happens before IE10 releases
  91. # [09:29] <fantasai> sylvaing: It's possible, but I can't commit to it.
  92. # [09:29] <fantasai> glazou: Should we make a difference here between trasforms and animations on one hand and transitions on the other?
  93. # [09:29] <fantasai> smfr: 2D Transforms and Transitions more stable, Animations next, 3D Transforms last
  94. # [09:30] <fantasai> dbaron: Think 2D Transforms , then Transitions, then 3D Transforms, then Animations
  95. # [09:30] <fantasai> dbaron: The Animations spec is such an incomprehensible mess.
  96. # [09:30] <fantasai> sylvaing: Difference between early webkit on one hand and opera/ff on another for Transitions
  97. # [09:31] <fantasai> jdaggett: Object model for animations is not implemented the same way
  98. # [09:31] <fantasai> Tab: Just talking about the properties, not OM stuff
  99. # [09:31] <fantasai> jdaggett: So you're saying that all can change, even in an unprefixed state?
  100. # [09:31] <fantasai> Tab: We don't worry too much about OM for animations too much, people don't use it much.
  101. # [09:31] <fantasai> dbaron: Are you talking about the constant thing?
  102. # [09:31] <fantasai> jdaggett: It's small, but key.
  103. # [09:31] <fantasai> smfr: I think we can fix that.
  104. # [09:32] <fantasai> jdaggett: You're saying there will be changes that affect implementations, but the syntax won't change.
  105. # [09:32] <fantasai> Tab: Right.
  106. # [09:32] <fantasai> Tab: If people think we have problems that will be fixed by grammar change, speak up.
  107. # [09:33] <fantasai> sylvaing: 2D Transforms most ready. For IE10, could drop prefixes. But if we change functional notation, will be hard.
  108. # [09:33] <fantasai> Tab: We agreed that even if we drop commas, we'd still accept with all commas
  109. # [09:33] <fantasai> sylvaing: I can see making an exception, but spec goes out as-is.
  110. # [09:34] <fantasai> jdaggett: I'm arguing for pushing to CR more quickly
  111. # [09:34] <fantasai> sylvaing: It would be more likely to drop prefixes if we don't change the functional notation
  112. # [09:34] <fantasai> Tab: What about transitions or animations?
  113. # [09:34] <fantasai> glazou: It's not only the syntax, Tab.
  114. # [09:34] <sylvaing> IE10 could *maybe* drop prefixes
  115. # [09:34] <fantasai> glazou: If we discover an inconsistentcy to fix, we might have to change syntax to avoid breaking websites.
  116. # [09:35] <dbaron> For the record, I agree with Tab's proposal for at least 2-D transforms and transitions, and maybe animations.
  117. # [09:35] <fantasai> glazou gives example of video editors, which we don't consider
  118. # [09:36] <fantasai> glazou: Changes can happen
  119. # [09:36] <fantasai> Tab: We are far too stable to change them.
  120. # [09:36] <fantasai> Tab: roc asked to drop prefixes 3 months ago, we havn't moved forward.
  121. # [09:36] <dbaron> s/maybe animations/animations/
  122. # [09:36] <fantasai> ...
  123. # [09:36] <fantasai> Bert: Let's make an LC then
  124. # [09:36] <fantasai> Tab: Are they ready for LC? There are still things that need to be cleaned up in the specs. They still haveissues
  125. # [09:37] <fantasai> Vincent: The merge effort has been raising parsing issues.
  126. # [09:37] <fantasai> dbaron: I don't think we should wait for the merge effort.
  127. # [09:37] <glazou> s/to change syntax/to change behaviour
  128. # [09:37] <fantasai> Vincent: I don't argue with that, but I think we should at least look at what the issues are. On the syntax side, see if there's anything pinning us into a bad corner in the future.
  129. # [09:37] <fantasai> Vincent: If we make a decision to move the spec forward, and that prevents the merge from happening, that's a problem.
  130. # [09:38] <fantasai> Vincent: As long as we don't paint ourselves into a corner, we can make tweaks later.
  131. # [09:38] <fantasai> smfr: I think most changes are relaxing the parsing rules.
  132. # [09:38] <fantasai> Vincent: May not be that bad. All I'm asking that we have the discussion of what the issues are.
  133. # [09:38] <fantasai> dbaron: Then I think we need to have that discussion today.
  134. # [09:38] <fantasai> Vincent: Dirk has posted issues and analysis, see smfr's link
  135. # [09:38] <smfr> http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#Differences_between_SVG_Transforms_and_CSS_Transforms
  136. # [09:39] <fantasai> Florian: If you find something that might be worth changing behavior for, we can do it, just can't do consideration for what might break.
  137. # [09:39] <fantasai> Florian: If it's nice to change, but not necessary, at this point might already be too late.
  138. # [09:39] <fantasai> sylvaing: There are sitll difference between ways implementations treat stacking context, etc.
  139. # [09:39] <fantasai> sylvaing: We also have a policy if you drop prefixes, you have to submit an implementation report. I don't wnat to make an excetion to that.
  140. # [09:40] <fantasai> sylvaing: We need to drive interoperability. If some small subset fo shiny demos work, that's not enough.
  141. # [09:40] <fantasai> glazou: Let's go to CR asap
  142. # [09:41] <fantasai> Florian: We could drop prefixes before CR. We just have to look through all the issues and make sure there are no other problems.
  143. # [09:41] <fantasai> Steve: Send to the list that want to go to CR ASAP, and ask for people to submit their issues ASAP.
  144. # [09:41] <fantasai> dbaron: We've submitted a bunch of tests for 2D and 3D transforms, and Aryeh's been adding to them practically daily.
  145. # [09:41] <fantasai> smfr: Unfortunately tests rely on undefined behavior.
  146. # [09:41] * Joins: kojiishi (kojiishi@128.93.135.158)
  147. # [09:42] <fantasai> Topic: Question from WAIPF WG
  148. # [09:42] <fantasai> Bert: They want 2 weeks more to review Images LC. Ask until Feb 22.
  149. # [09:43] * Joins: antonp (805d879d@64.62.228.82)
  150. # [09:43] <fantasai> fantasai: Can we ask them to send any identified issues as soon as they have them, so we can start addressing them, rather than waiting to collect them all and submit at the end?
  151. # [09:43] <florian> s/make sure there are no other problems/make sure that the issues that remain to be solved can safely be solved after dropping prefixes/
  152. # [09:43] <fantasai> glazou: Probably don't have identified issues yet, just a time constraint.
  153. # [09:43] <fantasai> glazou: Any reason to answer no?
  154. # [09:43] <fantasai> glazou: Ok, resolved.
  155. # [09:44] <fantasai> RESOLVED: WAIPF gets until 22nd of February to send LC comments.
  156. # [09:44] <fantasai> Topic: CSS2.1 Errata
  157. # [09:45] * fantasai finds it odd that people want to implement webkit prefixed properties, but same people don't want to drop prefixes
  158. # [09:45] <fantasai> plinss: Would not want to spend all f2f time on 2.1 issues
  159. # [09:46] <fantasai> anton: Agree. Just these 6 issues would benefit from all implementers being present here
  160. # [09:46] <fantasai> plinss: If just need implementers, might make sense to do a small subset f2f with just those people
  161. # [09:46] <fantasai> plinss: Get all the proposals together, and then bring to WG for approval.
  162. # [09:47] <fantasai> Alan: could be a day or two before or after
  163. # [09:47] <fantasai> Anton: Requires impelemnters to have time to sit down and think about it.
  164. # [09:47] <antonp> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15702
  165. # [09:48] * Joins: howcome (howcome@128.93.135.45)
  166. # [09:48] <dbaron> testcase: https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
  167. # [09:49] <fantasai> dbaron: Don't know if we checked what IE10 did
  168. # [09:50] <fantasai> ...
  169. # [09:50] <fantasai> dbaron: I'm not sure what happens if the root is floated. Might have ICB establish a BFC, too.
  170. # [09:50] <fantasai> anton: There does have to be an inicial BFC.
  171. # [09:50] <fantasai> Anton: Question is does the root element also establish a BFC
  172. # [09:51] <dbaron> Based on that testcase, WebKit and Gecko consider the root to be a BFC and IE9 and Opera do not.
  173. # [09:52] * Quits: antonp (805d879d@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
  174. # [09:53] <dbaron> sylvain, rossen: IE10 matches IE9
  175. # [09:53] <fantasai> fantasai: So what's the next step here?
  176. # [09:54] <fantasai> dbaron: I happen to think Gecko is wrong here.
  177. # [09:54] <fantasai> Anton: Do you think there ought to be an initial BFC?
  178. # [09:54] <fantasai> dbaron: Yes
  179. # [09:54] <fantasai> Rossen: That one I agree with.
  180. # [09:55] <fantasai> Anton: So the root element does not establish a BFC, but it participates in one stablished by the ICB
  181. # [09:55] <fantasai> sylvaing: I would like Arron to review this proposal.
  182. # [09:56] <fantasai> ACTION Florian: Check with Opera that this is okay
  183. # [09:56] * trackbot noticed an ACTION. Trying to create it.
  184. # [09:56] * RRSAgent records action 1
  185. # [09:56] <trackbot> Created ACTION-437 - Check with Opera that this is okay [on Florian Rivoal - due 2012-02-15].
  186. # [09:56] <fantasai> ACTION Sylvain: Check with Arron that this is okay
  187. # [09:56] * trackbot noticed an ACTION. Trying to create it.
  188. # [09:56] * RRSAgent records action 2
  189. # [09:56] <trackbot> Sorry, couldn't find user - Sylvain
  190. # [09:57] <fantasai> Anton: Interaction of scrollbars with CSS box model is not well-defined.
  191. # [09:57] <fantasai> Anton: Interesting sentence in question is in 11.1.1
  192. # [09:58] * fantasai wants a link in the minutes, ehllo
  193. # [09:58] <astearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15880
  194. # [09:58] <fantasai> Anton reads the bug report
  195. # [10:02] <fantasai> fantasai tries to explain what the spec says
  196. # [10:02] <fantasai> dbaron: We need testcases to determine what happens
  197. # [10:02] <fantasai> smfr: Also need to leave some things up to UA; in OS X the scrollbar just hovers over the content.
  198. # [10:02] <fantasai> dbaron: I think we need an action item for someone to write a bunch of testcases
  199. # [10:02] <fantasai> Florian: On the previous item, behavior hasn't changed.
  200. # [10:02] <fantasai> Rossen: So you're ok with the resolution?
  201. # [10:02] <fantasai> Florian: Sure
  202. # [10:04] <fantasai> fantasai: I think the spec makes sense here when width is auto, but doesn't make sense when it's not auto.
  203. # [10:04] <fantasai> dbaron says something about shrinkwrap
  204. # [10:05] <fantasai> dbaron: I think the spec is internally contensistent for [...] but doesn't match implementations
  205. # [10:05] <fantasai> fantasai: I'm unsure about shrinkwrap case, but I think the sentence in the bug report makes sense for auto width in non-shrinkwrap case.
  206. # [10:05] * Joins: alexmog_ (qw3birc@128.30.52.28)
  207. # [10:06] <fantasai> fantasai: I think the testcases you need are fixed width, auto width, shrinkwrap width
  208. # [10:06] <fantasai> dbaron: and height
  209. # [10:06] <astearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392
  210. # [10:06] <dbaron> ACTION anton to create tests for https://www.w3.org/Bugs/Public/show_bug.cgi?id=15880
  211. # [10:06] * trackbot noticed an ACTION. Trying to create it.
  212. # [10:06] <trackbot> Created ACTION-438 - Create tests for https://www.w3.org/Bugs/Public/show_bug.cgi?id=15880 [on Anton Prowse - due 2012-02-15].
  213. # [10:06] <fantasai> Anton reads from bug report
  214. # [10:08] <fantasai> fantasai: I don't think you can make the used value auto. You can treate a computed value of a percentage as auto in the calculations, but used value needs to be an absolute length
  215. # [10:10] <fantasai> fantasai: All you need to change is in that sentence where it says "The value computes to 'auto'" say "the value is treated as 'auto' for the purpose of calculating the used value"
  216. # [10:10] <fantasai> (and fix the computed value line)
  217. # [10:10] <fantasai> dbaron: I think that's fine.
  218. # [10:10] <fantasai> RESOLVED: Proposal accepted
  219. # [10:11] <astearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15389
  220. # [10:12] <fantasai> Anton proposes leaving the problem of having an overly-broad undefined clause to be solved in CSS3
  221. # [10:13] <fantasai> dbaron: Bug says there are cases that should be undefined that aren't.
  222. # [10:15] <fantasai> [people generally agree that making more than necessary undefined is okay; issue of things that needt to be undefined but aren't should be handled -- deferred to later]
  223. # [10:15] <fantasai> Topic: Media Queries
  224. # [10:16] <fantasai> Florian: When defining <resolution> in MQ, we didn't specify whether they are CSS in and cm, or whether they follow the usual definition
  225. # [10:16] <dbaron> http://dev.w3.org/csswg/css3-mediaqueries/#units
  226. # [10:16] <fantasai> dbaron: So the first sentence of section 6
  227. # [10:17] <fantasai> dbaron: "The units used in Media Queries are the same as in other parts of CSS. For example, 'px' represents CSS px, not device pixels."
  228. # [10:17] <fantasai> Florian: Definition of dpi doesn't say though
  229. # [10:17] <fantasai> Florian: Also other spec that redefines <resolution> makes it explicit that these are CSS inches etc.
  230. # [10:17] <fantasai> Florian: But this spec is not explicit.
  231. # [10:18] * Joins: antonp (805d879d@109.169.29.95)
  232. # [10:18] <fantasai> ...
  233. # [10:18] <fantasai> fantasai: dots are device pixels
  234. # [10:18] <fantasai> Question is what is the inch.
  235. # [10:18] <fantasai> dbaron: I think in our case it's a physical inch, not a CSS inch.
  236. # [10:19] <fantasai> sylvaing: Do you want number of device pixels per CSS inch or per physical inch?
  237. # [10:19] <dbaron> http://dev.w3.org/csswg/css3-images/#resolution-units
  238. # [10:21] <fantasai> Steve: I think dp physical inch makes most sense
  239. # [10:21] * Bert thinks we can go ask what an inch is: We're in Paris, not far from http://en.wikipedia.org/wiki/International_Bureau_of_Weights_and_Measures :-)
  240. # [10:21] <fantasai> fantasai: Problem is that if you try to use resolution and width to calculate the dots across the width, you can't if the inches don't match up
  241. # [10:23] <fantasai> dbaron: What are people using resolution for?
  242. # [10:23] <fantasai> Florian: They aren't, they're using device-pixel-ratio
  243. # [10:25] * Joins: lar_zzz (Adium@79.226.80.18)
  244. # [10:25] <fantasai> sylvaing: What do you do with that?
  245. # [10:25] <fantasai> smfr: You decide whether you load high-res implementations or not.
  246. # [10:25] <fantasai> dbaron: I would like to know what other implementations do, since this has been in CR a long time
  247. # [10:25] <fantasai> Florian: We implemented CSS inches for a long time. On mobile we use physical inches
  248. # [10:26] <dbaron> Florian: We did CSS inches for a long time, but recently started, on mobile-only, doing physical inches, but only on mobile.
  249. # [10:26] <fantasai> s/use/now use/
  250. # [10:26] <fantasai> plinss: Being inconsistent makes no sense
  251. # [10:26] <fantasai> dbaron: Doing CSS sizes is much harder because you have to proxy all your device pixel ratio compuations into resolution
  252. # [10:27] <fantasai> dbaron: I guess we just compute it entirely ...
  253. # [10:27] <fantasai> dbaron: But that would mean you can't get the physical size of the device.
  254. # [10:27] <fantasai> Florian: This doesn't give you physical size of a display
  255. # [10:28] <fantasai> dbaron: I wrote a script that did multi-step computation to find the physical size of a device
  256. # [10:29] <fantasai> Steve, summarizing Florian: The CSS pixel is intended to encapsulate viewing distance and size together because that's what actually matters to the viewer.
  257. # [10:30] <fantasai> plinss: I think if we interpret inches differently in different places we're asking for trouble.
  258. # [10:30] <fantasai> ChrisL: Does that mean you can get the number of physical dots per CSS px.
  259. # [10:30] <fantasai> ChrisL: If so, what do you get from a printer?
  260. # [10:31] <fantasai> Tab: What's the problem here?
  261. # [10:31] <fantasai> Tab: Are printers lower-res than dots?
  262. # [10:31] <fantasai> ChrisL: The screen resolution is a lot smaller than the device resolution
  263. # [10:32] <fantasai> ChrisL: for a printer
  264. # [10:32] <fantasai> ChrisL: they combine ink colors to make a color
  265. # [10:32] <fantasai> smfr: Webkit doesn't support 'resolution'
  266. # [10:33] <fantasai> ChrisL: So should we clarify printer situation?
  267. # [10:33] <fantasai> Tab: Yes, let's clarify that the device pixel in this case is the dot of arbitrary color.
  268. # [10:33] <fantasai> ChrisL: So the screening resolution
  269. # [10:33] <fantasai> Florian: The whole point of this is to supply high-res images
  270. # [10:34] * sylvaing is now known as sylvaing_away
  271. # [10:34] <fantasai> ChrisL: but if they're choosing high-res vs low-res images, and they get back 200dpi from the printer as the screen res?
  272. # [10:35] <fantasai> ChrisL: The author who wants to figure out whether they have a high-res printer will expect 1200dpi
  273. # [10:35] <fantasai> Tab: Difference between high-res screen (~200dpi) and printer should be easy to distinguish
  274. # [10:36] <fantasai> ChrisL: A typical screening resolution is 175dpi
  275. # [10:36] <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Apr/thread.html#msg126
  276. # [10:36] <fantasai> fantasai: Question is, if the screening resolution is 200dpi and the other resolution is 1000dpi, do I send the printer a 200dpi image or a 1000dpi image?
  277. # [10:37] * Joins: drublic (drublic@77.2.157.148)
  278. # [10:37] <fantasai> dbaron: I don't see this thread having a clear conclusion
  279. # [10:37] <fantasai> Tab: Answer to original question of whether dots are CSS px or device px
  280. # [10:37] <dbaron> oh, wait, that was about the dot part rather than the inch part
  281. # [10:38] <fantasai> Koji: To answer fantasai's question, if it's a monochrome image you should use 1000dpi, and if it's color or grayscale you should send 200dpi
  282. # [10:39] <fantasai> fantasai: We can't make that distinction in Media Queries
  283. # [10:40] <fantasai> fantasai: To make that distinction you need both resolutions, and we're only providing one.
  284. # [10:40] * sylvaing_away is now known as sylvaing
  285. # [10:41] <fantasai> ChrisL: The author can assume that 1000dpi gets you 200dpi screening
  286. # [10:41] <fantasai> fantasai: What if someone creates a device that has screening 600dpi
  287. # [10:42] <fantasai> Steve: Why not add a media query on screening?
  288. # [10:42] <fantasai> ChrisL: You need the physcial dots per incha as well.
  289. # [10:42] <fantasai> Steve: No, instead of reporting actual results, ... it has to be reported with the same assumptions as the other resolutions.
  290. # [10:43] <fantasai> Steve: If you add a media query for screening, it's going to report information back. All i'm saying is that as long as the information is reported using the same assumptions as the other media query things, that will tell you whether the dpi is different from screening resolution and by how much.
  291. # [10:43] <fantasai> ChrisL: Given what you've just said, if I have high-res printer, what number do I send back?
  292. # [10:44] <fantasai> fantasai: Most people send images that are more than one color. So we should return the resolution that is applicable to that.
  293. # [10:45] <fantasai> fantasai: and add a media query that gives the other number
  294. # [10:45] <fantasai> ChrisL: Add "Therefore for printers this is the screening resolution."
  295. # [10:45] <fantasai> tab: Need explanation for non-[printer-geeks
  296. # [10:45] <fantasai> fantasai: I like Tab's suggestion of "dot of arbitrary color".
  297. # [10:45] <fantasai> ChrisL: Should have both.
  298. # [10:46] <fantasai> sylvaing: Since when we zoom, we change the number of physical pixel to CSS px
  299. # [10:46] <fantasai> sylvaing: As soon as you zoom, you change whether the media query matches
  300. # [10:47] <fantasai> fantasai: you have the same problem with device-width, which is already known to be in CSS inches.
  301. # [10:48] <fantasai> fantasai: you need to exclude zoom from this.
  302. # [10:48] <fantasai> dbaron: I think FF has a bug with zooming
  303. # [10:48] <fantasai> dbaron: But I don't think what happens with zooming correlates with whether we're also including snapping to CSS px/in definition
  304. # [10:49] <fantasai> Florian: So based on that you're comfortable defining in terms of CSS px
  305. # [10:49] <fantasai> sylvaing: seems like it
  306. # [10:49] <fantasai> Rossen: Looking through the code it looks like we are doing CSS px/in
  307. # [10:50] <fantasai> plinss: Proposed to resolve as dpi/dpcm in CSS inches/cm
  308. # [10:50] <fantasai> dbaron: I'm not particularly happy with it, but okay.
  309. # [10:50] <fantasai> Florian: Unhappy that we're changing now, or unhappy about what we're changing to.
  310. # [10:51] <fantasai> Florian: We have to change too. Allowing use of 'resolution' in place of 'device-pixel-ratio' also makes more sense this way
  311. # [10:51] <fantasai> sylvaing: This is the author-facing behavior.
  312. # [10:51] <fantasai> sylvaing: it's got to be CSS px/in
  313. # [10:52] <fantasai> dbaron: Can I tentatively accept and double-check with roc?
  314. # [10:52] <fantasai> Bert: Question about what this means. It's confusing.
  315. # [10:52] <fantasai> Bert: So I'm looking at iphone display, sold as 300dpi
  316. # [10:52] <fantasai> Bert: What would be the CSS resolution in that case?
  317. # [10:52] <fantasai> Florian: It depends
  318. # [10:53] <fantasai> plinss: You're in the mobile pinch-zoom world,
  319. # [10:53] <fantasai> Florian: Fairly likely that resolution in dppx would be 2
  320. # [10:53] <fantasai> dbaron: It would be 192dpi
  321. # [10:53] <fantasai> sylvaing: When you do zoom in FF, what do you do?
  322. # [10:53] * Joins: miketaylr (miketaylr@200.188.44.208)
  323. # [10:53] <fantasai> dbaron: I don't actually know
  324. # [10:54] <fantasai> sylvaing: talks about a testcase that changes bg color
  325. # [10:54] <Bert> s/300dpi/326dpi/
  326. # [10:54] <fantasai> Florian: Is anyone aware of common use of 'resolution' in the wild
  327. # [10:54] <fantasai> dbaron: Probably not bc webkit doesn't implement it
  328. # [10:55] <fantasai> RESOLVED: dpi/dpcm in 'resolution' media query uses CSS units. Tentatively resolved pending roc's approval.
  329. # [10:55] * Joins: ChrisL (ChrisL@128.30.52.169)
  330. # [10:55] <fantasai> plinss: To close loop on Chris's tangent on screening.
  331. # [10:57] <fantasai> fantasai: The proposal is to define resolution as screening resolution, and explain what that means.
  332. # [10:57] <fantasai> Section 4.11
  333. # [10:57] * Quits: karl (karlcow@128.30.54.58) (Client exited)
  334. # [10:57] <fantasai> Append after the first paragraph in the 'resolution' section
  335. # [10:58] <fantasai> "For printers, this corresponds to the screening resolution (the resolution for printing dots of arbitrary color)."
  336. # [10:59] <fantasai> RESOLVED: Accept proposal for clarifying 'resolution' MQ for printers.
  337. # [10:59] <fantasai> ACTION Florian: File an issue on MQ4 about adding the other resolution (for monochrome printing)
  338. # [10:59] * trackbot noticed an ACTION. Trying to create it.
  339. # [10:59] * RRSAgent records action 3
  340. # [10:59] <trackbot> Created ACTION-439 - File an issue on MQ4 about adding the other resolution (for monochrome printing) [on Florian Rivoal - due 2012-02-15].
  341. # [11:00] * Joins: szilles (chatzilla@128.93.135.13)
  342. # [11:11] * Joins: miketayl_r (miketaylr@200.188.44.208)
  343. # [11:11] * Quits: miketaylr (miketaylr@200.188.44.208) (Connection reset by peer)
  344. # [11:22] * Quits: howcome (howcome@128.93.135.45) (Ping timeout)
  345. # [11:23] <TabAtkins_> ScribeNick: TabAtkins_
  346. # [11:24] <smfr> http://dev.w3.org/csswg/css3-exclusions/
  347. # [11:24] <TabAtkins_> Rossen: We've made a few changes since the last f2f
  348. # [11:24] <TabAtkins_> Rossen: We've had several issues raised during TPAC that we recorded in bugzilla.
  349. # [11:24] <TabAtkins_> Rossen: We tried to address as many as we could.
  350. # [11:24] <TabAtkins_> Rossen: We wanted to go over the remaining issues.
  351. # [11:25] <TabAtkins_> Rossen: Simple one first.
  352. # [11:25] <TabAtkins_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15088
  353. # [11:26] <TabAtkins_> Rossen: previously we were using fixed-height examples, so it was hard to see the effect of auto height stuff.
  354. # [11:26] <TabAtkins_> Rossen: Next, we took the updated syntax from Tab from Monday.
  355. # [11:27] <TabAtkins_> Rossen: Related to that was the bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=15091
  356. # [11:27] <TabAtkins_> Rossen: This was asking if we need to simplify the syntax for shapes.
  357. # [11:27] <TabAtkins_> Rossen: Questions were raised related to this - do we need them at all?
  358. # [11:27] <TabAtkins_> Rossen: And if we did, do we need all of them, and which ones?
  359. # [11:28] <TabAtkins_> Rossen: We discussed this quite a bit, and we still feel pretty strongly that we need to give users that are hand-authoring the ability to create something simple and straightforward.
  360. # [11:28] <TabAtkins_> Rossen: rectangle, circle, and ellipse definitely fit in that.
  361. # [11:28] <TabAtkins_> Rossen: Polygon, once you move past a few points, is a little hard, but still doable.
  362. # [11:28] <TabAtkins_> Rossen: So our answer is that we want to keep the declarative syntax.
  363. # [11:29] <TabAtkins_> Rossen: And the set of primitives we're suggesting is sufficient.
  364. # [11:29] <TabAtkins_> howcome: Shapes can be useful. We don't have a history of them in CSS.
  365. # [11:30] <TabAtkins_> howcome: The problem of using shapes, in one of the examples, is that you write a shape that follows the outline of a font.
  366. # [11:30] <TabAtkins_> howcome: But if that font isn't available, your shape will not match what the user sees.
  367. # [11:30] <TabAtkins_> howcome: So by separating the shape and the data, this is a problem.
  368. # [11:32] <TabAtkins_> ChrisL: What were the other issues with shapes in CSS?
  369. # [11:32] <vhardy_> q+
  370. # [11:32] * Zakim sees vhardy_ on the speaker queue
  371. # [11:32] <TabAtkins_> ChrisL: I recall they just didn't have very tight definitions. They weren't ever given a chance.
  372. # [11:33] <TabAtkins_> vhardy_: It seems that both are useful. Looks like defining the shape from text hasn't been addressed yet.
  373. # [11:33] <TabAtkins_> vhardy_: I think that shapes are still useful.
  374. # [11:34] <TabAtkins_> plinss: I think what's being asked for then is "use the visible content of this element".
  375. # [11:34] <astearns> q+
  376. # [11:34] * Zakim sees vhardy_, astearns on the speaker queue
  377. # [11:34] <Bert> q+ to raise minor editorial point: 4.1.1 says "SVG shapes," but the SVG shapes are actually in section 4.1.2. Section 4.1.1 is about CSS shapes.
  378. # [11:34] * Zakim sees vhardy_, astearns, Bert on the speaker queue
  379. # [11:34] <plinss> ack vhardy
  380. # [11:34] * Zakim sees astearns, Bert on the speaker queue
  381. # [11:34] <plinss> ack astearns
  382. # [11:34] * Zakim sees Bert on the speaker queue
  383. # [11:35] <TabAtkins_> astearns: There's one example where a shape is meant to correspond to rendered content, but there are other examples where the shape *doesn't* correspond to rendered content. There you want shapes.
  384. # [11:35] <TabAtkins_> ChrisL: And in some cases you have a raster image with an alpha, but you don't actually want to use that alpha channel; you want a simplified outline around it.
  385. # [11:36] <TabAtkins_> TabAtkins_: So it sounds like shapes are great, but you also want a currently-missing ability to wrap around some rendered content.
  386. # [11:36] <TabAtkins_> Bert: [brings up the editorial issue noted above]
  387. # [11:36] <TabAtkins_> Rossen: Agreed.
  388. # [11:36] * Quits: miketayl_r (miketaylr@200.188.44.208) (Ping timeout)
  389. # [11:38] <TabAtkins_> TabAtkins_: When I've manually done exclusions by splitting an image into bands and floating it, I generally do things that would be fine with shapes.
  390. # [11:38] <TabAtkins_> [some unminuted discussion about the applicability of using alpha channel with a margin]
  391. # [11:39] <vhardy_> q+
  392. # [11:39] * Zakim sees Bert, vhardy_ on the speaker queue
  393. # [11:39] <Bert> q-
  394. # [11:39] * Zakim sees vhardy_ on the speaker queue
  395. # [11:40] <TabAtkins_> howcome: I recognize the value of the shapes, but I don't know if they're useful for level 1.
  396. # [11:40] <TabAtkins_> howcome: I think we should start with the simple stuff first, and that's images.
  397. # [11:40] <glazou> Zakim, ack vhardy
  398. # [11:40] <Zakim> I see no one on the speaker queue
  399. # [11:40] <TabAtkins_> [several]: No, shapes are much simpler.
  400. # [11:41] <TabAtkins_> vhardy_: From a tooling perspective, people often draw shapes with those tools, rather than extracting from a raster image or something.
  401. # [11:41] * Bert expects to do this most of the time: 'img {float: left; shape-outside: attr(src, url); shape-threshold: 0}'
  402. # [11:41] <TabAtkins_> vhardy_: One example in the spec has a car against a mountain background, with the text flowing around the car, and that's fairly difficult to threshold from the image. It's a large image, too, so sending down a second image for the alpha mask would be costly.
  403. # [11:42] <TabAtkins_> plinss: Hakon's point is valid that we shouldn't have people forced to use shapes for things like wrapping around letters. As long as there are options to handle those properly too, it should work, and we can have shapes too.
  404. # [11:43] * Bert would still like to do it as proposed in 1996 or so: 'img {float: left contour}'...
  405. # [11:44] <TabAtkins_> ACTION vincent to add issue about handling visible content as a shape for Exclusions.
  406. # [11:44] * trackbot noticed an ACTION. Trying to create it.
  407. # [11:44] <trackbot> Created ACTION-440 - Add issue about handling visible content as a shape for Exclusions. [on Vincent Hardy - due 2012-02-15].
  408. # [11:44] <TabAtkins_> Rossen: Next topic is a bug about animated images.
  409. # [11:44] <TabAtkins_> Rossen: Our proposal was something we all got an agreement with at TPAC, where everyone felt either first or last frame.
  410. # [11:45] <TabAtkins_> Rossen: Looking at default GIF behaviors, first frame is always the "default" when it's treated as a still image - in print, when animations are disabled, etc.
  411. # [11:45] <TabAtkins_> Rossen: So using first frame seems the most sensible.
  412. # [11:45] * Joins: szilles_ (chatzilla@193.105.139.131)
  413. # [11:46] <TabAtkins_> plinss: And we can always add a property if we decide it's not crazy later.
  414. # [11:46] <TabAtkins_> plinss: Can a GIF cycle just once?
  415. # [11:46] <TabAtkins_> vhardy_: yes.
  416. # [11:46] <TabAtkins_> plinss: In that case, it stops on the last frame, right?
  417. # [11:47] <TabAtkins_> plinss: It might make sense to use the last frame for that.
  418. # [11:47] <TabAtkins_> vhardy_: SVG animations similarly can run once, and it's somewhat hard to wrap for the last shape there, since it can have script.
  419. # [11:47] * Quits: szilles (chatzilla@128.93.135.13) (Ping timeout)
  420. # [11:47] * szilles_ is now known as szilles
  421. # [11:47] <TabAtkins_> Rossen: So I think first frame is still the safest option there.
  422. # [11:48] <TabAtkins_> smfr: For SVG, "first frame" is the image without any animations?
  423. # [11:48] <TabAtkins_> vhardy_: Yes.
  424. # [11:49] <TabAtkins_> ACTION vhardy to add a note to Exclusions that animated images use the first frame (in SVG, render the image without animations).
  425. # [11:49] * trackbot noticed an ACTION. Trying to create it.
  426. # [11:49] <trackbot> Created ACTION-441 - Add a note to Exclusions that animated images use the first frame (in SVG, render the image without animations). [on Vincent Hardy - due 2012-02-15].
  427. # [11:50] <TabAtkins_> ChrisL: We want to write it in such a way, though, that later specs *can*, say, respond to animated SVG.
  428. # [11:50] <TabAtkins_> vhardy_: it seems we can add a property in the future to control that sensibly.
  429. # [11:50] <TabAtkins_> TabAtkins_: Agreed - this seems future-friendly.
  430. # [11:51] <TabAtkins_> Rossen: Next issue is from Bert, about "contour"
  431. # [11:54] <TabAtkins_> Bert: It's about an idea a long time ago, that when you use an image both for rendering and masking, to make it easy to specify that without writing the url twice.
  432. # [11:54] <TabAtkins_> vhardy_: It seems that this is similar to the previous idea of wrapping based on the visible content of some element.
  433. # [11:54] <TabAtkins_> astearns: It seems we're proposing you can get a shape out of an alpha channel, or out of rendered content. So if we're trying to avoid duplicated urls, we'd need multiple keywords.
  434. # [11:55] <TabAtkins_> ACTION vhardy to investigate using the content of an <img> for wrapping without duplicating the url, in light of earlier discussion about shaping from rendered content.
  435. # [11:55] * trackbot noticed an ACTION. Trying to create it.
  436. # [11:55] <trackbot> Created ACTION-442 - Investigate using the content of an <img> for wrapping without duplicating the url, in light of earlier discussion about shaping from rendered content. [on Vincent Hardy - due 2012-02-15].
  437. # [11:55] <Bert> ('img {float: left contour}' instead of 'img {float: left; shape-outside: attr(src, url)}')
  438. # [11:55] * Joins: jet (jet@128.93.134.216)
  439. # [11:55] <TabAtkins_> howcome: Another issue - this spec says it can be used with any positioning scheme.
  440. # [11:55] <vhardy_> q+
  441. # [11:55] * Zakim sees vhardy_ on the speaker queue
  442. # [11:56] <Bert> (... except that it is independent of which attribute the URL comes from.)
  443. # [11:57] <TabAtkins_> howcome: So how do we get interop if some impls use exlusions with some positioning schemes, while others do it with others.
  444. # [11:57] <TabAtkins_> astearns: The intention of that sentence is that it works with *all* of them.
  445. # [11:57] <dbaron> dbaron: This is very interrelated to positioning schemes, since its exclusions order model works in the reverse of the way most positioning schemes place content.
  446. # [11:57] <TabAtkins_> howcome: But it's rather complex. What will you test? What if you set an exclusion on a table cell?
  447. # [11:58] <TabAtkins_> szilles: If you write the conformance criteria, you'll wind up answering the technical questions based on what you write there.
  448. # [11:58] <dbaron> And for the record, roc is ok with the proposed change to the resolution media query.
  449. # [11:59] <TabAtkins_> TabAtkins_: So we should have a decent explanation for how each positioning scheme interacts with exclusions (and possibly regions too).
  450. # [11:59] <TabAtkins_> howcome: For example, floats are exclusions already.
  451. # [12:00] <TabAtkins_> alexmog_: It needs to explicitly say what happens with abspos, and with float.
  452. # [12:00] <TabAtkins_> alexmog_: But other specs should mention how they work with exclusions.
  453. # [12:01] <TabAtkins_> howcome: [draws an example on the board with a float, and asks what happens if it becomes an exclusion]
  454. # [12:01] <TabAtkins_> Rossen: Right now, the spec says that floats can't be exclusions.
  455. # [12:01] <TabAtkins_> howcome: Good answer.
  456. # [12:02] <TabAtkins_> Rossen: Also, as an impl experiment, I did floats using exclusions and it worked. Less performant, but it worked.
  457. # [12:02] <smfr> q+
  458. # [12:02] * Zakim sees vhardy_, smfr on the speaker queue
  459. # [12:02] <TabAtkins_> astearns: We do specifically mention how floats work with this.
  460. # [12:03] <TabAtkins_> szilles: So if we have a section called "Positioning Schemes" that lists the schemes and any additional constraints that are introduced, it should satisfy hakon.
  461. # [12:03] <TabAtkins_> Rossen: That sounds pretty good. It would address testability.
  462. # [12:04] <TabAtkins_> howcome: If they don't work with floats, what if I have a float and want it to have a shape?
  463. # [12:04] <TabAtkins_> alexmog_: I think that anything in 2.1 that interacts with Exclusions should go in the Exclusions spec. New positioning schemes should talk about Exclusions in their own spec.
  464. # [12:04] <plinss> q?
  465. # [12:04] * Zakim sees vhardy_, smfr on the speaker queue
  466. # [12:05] <plinss> ack vhardy
  467. # [12:05] * Zakim sees smfr on the speaker queue
  468. # [12:05] <plinss> ack smfr
  469. # [12:05] * Zakim sees no one on the speaker queue
  470. # [12:05] <TabAtkins_> smfr: It concerns me if a spec like exclusions has to reference a bunch of other specs about layout models.
  471. # [12:05] <TabAtkins_> smfr: I would much prefer it if exclusions could reference CSS fundamentals like the box model, rather than referencing specific positioning schemes.
  472. # [12:05] <TabAtkins_> smfr: maybe we don't have the right fundamentals defined yet, but it seems dangerous to do anything else, or else we'll have combinatorial explosions.
  473. # [12:06] <TabAtkins_> vhardy_: I think that was the original intent. We had a two-pass algorithm that let it be defined simply by finding the position of each element, then the effect of each element.
  474. # [12:07] <TabAtkins_> Bert: It's doable in practice. If you refer to the box model, it needs an intrinsic width.
  475. # [12:07] <Bert> s/doable/probably not doable/
  476. # [12:07] <TabAtkins_> howcome: I think with floats, how can you position them in the first pass? You need to lay out the content first.
  477. # [12:07] <TabAtkins_> szilles: I think we're getting sidetracked
  478. # [12:08] <TabAtkins_> howcome: Possibly not. If the processing model in Exclusions excludes certain positioning schemes (particularly floats), then we have a problem. Then it's no longer agnostic.
  479. # [12:09] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  480. # [12:09] <Bert> (My colleague Dom once extracted a tree of dependencies from our modules. Maybe we should make a cron job that makes that tree every week or so, so we can check that it is indeed still a tree...)
  481. # [12:09] <TabAtkins_> szilles: To simon's point, embedding references to particular other specs can produce a rats nest of cross-references. But there's an equal problem of *not* specifying what schemes were assumed at the time the specs were written.
  482. # [12:09] <vhardy_> q+
  483. # [12:09] * Zakim sees vhardy_ on the speaker queue
  484. # [12:10] <TabAtkins_> smfr: Is it an issue with constraints, or is it an ordering problem as well? Do exclusions first, then layout, or something like thta?
  485. # [12:10] <plinss> ack next
  486. # [12:10] * Zakim sees vhardy_ at the head of the speaker queue
  487. # [12:10] * Zakim sees no one on the speaker queue
  488. # [12:11] <TabAtkins_> vhardy_: I don't think we'll resolve this today. Can we take an action to work out the processing model further, and demonstrate how it works with the existing positioning schemes.
  489. # [12:11] <TabAtkins_> szilles: The results of those experiments will tell you what to put in the spec.
  490. # [12:12] <TabAtkins_> ACTION vhardy to investigate the processing model of Exclusions further, and report results/figure out what to put in the spec for various layout modes.
  491. # [12:12] * trackbot noticed an ACTION. Trying to create it.
  492. # [12:12] <trackbot> Created ACTION-443 - Investigate the processing model of Exclusions further, and report results/figure out what to put in the spec for various layout modes. [on Vincent Hardy - due 2012-02-15].
  493. # [12:13] <TabAtkins_> howcome: New issue! We should really use background images as a source for exclusion shapes.
  494. # [12:13] <TabAtkins_> howcome: We have a lot of tools for background images right now, and should just reuse those.
  495. # [12:13] <TabAtkins_> glazou: I agree. I don't know if it's compatible with your current model, but it's a novel way of doing things that's consistent with some graphical editors.
  496. # [12:14] <TabAtkins_> Rossen: When we did all the model analysis and comparisons, your proposal was one of those.
  497. # [12:14] <TabAtkins_> Rossen: At the time we discussed it and we agreed that it wasn't desirable.
  498. # [12:14] <TabAtkins_> Rossen: but actually, it would fit with what we have now.
  499. # [12:15] <TabAtkins_> Rossen: Only difference is, when we use background images, the exclusion will be part of the wrapping content of the element itself, but wouldn't make the element itself an exclusion.
  500. # [12:15] <TabAtkins_> s/wrapping content/wrapping context/
  501. # [12:15] <TabAtkins_> Rossen: Which glazou disagreed with in Seattle.
  502. # [12:16] <TabAtkins_> glazou: yes, and I commented on it. It's different, but both are useful.
  503. # [12:16] <TabAtkins_> ACTION vhardy to add background-image support to the Exclusions spec
  504. # [12:16] * trackbot noticed an ACTION. Trying to create it.
  505. # [12:16] <trackbot> Created ACTION-444 - Add background-image support to the Exclusions spec [on Vincent Hardy - due 2012-02-15].
  506. # [12:16] <Bert> q+ to mention a possibly unrelated association: dark text on dark backgrounds...
  507. # [12:16] * Zakim sees Bert on the speaker queue
  508. # [12:16] <TabAtkins_> smfr: There may also be utility for using border-image support for the shape outside the box.
  509. # [12:18] <TabAtkins_> smfr: I was thinking of something like a rounded rectangle with some flourishes, or a picture-frame shape, with bumps on the corners but straight sides, and using that as an exclusion.
  510. # [12:18] <TabAtkins_> Rossen: Sounds like you're signing up for it.
  511. # [12:18] <TabAtkins_> astearns: We should probably put all of these ideas in the spec and then trim afterwards.
  512. # [12:18] <TabAtkins_> vhardy_: We'll at least put a note in about border-image, yes.
  513. # [12:19] <TabAtkins_> howcome: Another issue. Our current float approach can implement roughly half of the examples in the spec.
  514. # [12:19] <TabAtkins_> howcome: It may be worth pointing that out - "if you want to use exclusions today, use floats with X method. This spec allows for more powerful stuff as well."
  515. # [12:20] * dbaron notes the minute taker can't hear the discussion
  516. # [12:20] <TabAtkins_> howcome: Possible also just remove the simple stuff entirely from Exclusions, since floats do it already.
  517. # [12:20] <TabAtkins_> howcome: We're defining the same functionality with two different properties.
  518. # [12:21] <TabAtkins_> Rossen: Exclusions can penetrate through BFCs, unlike floats.
  519. # [12:21] <TabAtkins_> Rossen: If you manage to position an exclusion over a table cell, it will penetrate through and affect it.
  520. # [12:22] <TabAtkins_> Rossen: The scope of the exclusion wrapping context is the containing block for the exclusion algorithm.
  521. # [12:22] * Bert to glazou & plinss: Bernard arrived
  522. # [12:22] <glazou> yep saw that
  523. # [12:22] <fantasai> ~_~ Why do people keep randomly CCing me on mails to www-style? I thought it was obvious that I'm subscribed already.
  524. # [12:23] <fantasai> </gripe>
  525. # [12:24] <TabAtkins_> TabAtkins_: I have no idea how this will work with Flexbox.
  526. # [12:24] * ChrisL a To with a cc to www-style, I could understand
  527. # [12:24] <TabAtkins_> alexmog_: Layout will happen without reference to exclusions.
  528. # [12:24] <ChrisL> q?
  529. # [12:24] * Zakim sees Bert on the speaker queue
  530. # [12:24] * sylvaing fantasai, because you are a WG Of One
  531. # [12:24] <TabAtkins_> TabAtkins_: So flexbox layout will happen normally, and then if an exclusion changes how the text lays out, it'll just overflow? That's fine.
  532. # [12:24] <TabAtkins_> dbaron: I don't think it's fine. It' *defined*, but I don't think it's what people want.
  533. # [12:25] <TabAtkins_> TabAtkins_: I think what people *want* is "iterate layout until stable".
  534. # [12:25] <TabAtkins_> dbaron: That's why I'm not very happy with this whole thing.
  535. # [12:25] <TabAtkins_> howcome: [draws a diagram showing an exclusion covering parts of four separate cells]
  536. # [12:26] <TabAtkins_> Rossen: It would make the cell taller because the text flows...
  537. # [12:27] <TabAtkins_> TabAtkins_: But that contradicts what Alex just said. He said the layout wouldn't be affected. If it *is* affected, I'm back to not knowing how Flexbox will work.
  538. # [12:27] <TabAtkins_> alexmog_: We need to explain this more carefully.
  539. # [12:28] * ChrisL did we notify Robin where to meet us?
  540. # [12:28] <TabAtkins_> Rossen: [shows a live example of an exclusion crossing an element.
  541. # [12:28] * TabAtkins_ chrisl, no, we didn't.
  542. # [12:31] <TabAtkins_> [discussion of rossen's example]
  543. # [12:32] <TabAtkins_> [summary: layout *is* affected by exclusions. The meaning of this with other layout models is confusing an unknown]
  544. # [12:32] <dbaron> we didn't get to the bit about how the way layout is affected is one-pass and therefore only works "correctly" when there's only one exclusion
  545. # [12:33] <dbaron> (in other words, the spec is broken)
  546. # [12:33] <TabAtkins_> howcome: A common use-case is to position a pullquote centered on a column rule. If it's abspos, then if you change the window size, it will no longer be centered.
  547. # [12:33] <TabAtkins_> howcome: This is example *number 1*.
  548. # [12:33] <alexmog_> q+
  549. # [12:33] * Zakim sees Bert, alexmog_ on the speaker queue
  550. # [12:34] <TabAtkins_> plinss: This seems out-of-scope. This is a generic problem of positioning schemes that can be handled outside of exclusions.
  551. # [12:34] <Bert> q+ later
  552. # [12:34] * Zakim sees Bert, alexmog_, Bert on the speaker queue
  553. # [12:34] <plinss> ack alexmog
  554. # [12:34] * Zakim sees Bert, Bert on the speaker queue
  555. # [12:34] <TabAtkins_> howcome: You're willing to put that positioning scheme as the required line for exclusions? If not, example number 1 can't be done.
  556. # [12:35] <TabAtkins_> alexmog_: If we look at togehter GCPM and exclusions, and there are holes or inconsistencies, we need to raise those as issues.
  557. # [12:35] * Quits: vhardy_ (qw3birc@128.30.52.28) (Ping timeout)
  558. # [12:35] <TabAtkins_> howcome: So are we willing to solve this use-case?
  559. # [12:36] <alexmog_> q-
  560. # [12:36] * Zakim sees Bert, Bert on the speaker queue
  561. # [12:36] <TabAtkins_> vhardy: I think we already took actions on trying to solve these problems.
  562. # [12:37] <TabAtkins_> szilles: Hakon, you were the author of GCPM floats. You have the obligation to take into account how that works with exclusions.
  563. # [12:37] <ChrisL> q+ Bert to say Bert is on the queue
  564. # [12:37] <TabAtkins_> howcome: That might be more multicol, but yeah.
  565. # [12:37] * Bert :-)
  566. # [12:37] * Zakim sees Bert, Bert on the speaker queue
  567. # [12:37] * Bert didn't even know Zakim was capable of queing people twice...
  568. # [12:37] * Bert ... but not three times, apparently.
  569. # [12:38] <TabAtkins_> szilles: You can't say *we* have to progress float positioning. That's your spec.
  570. # [12:38] <ChrisL> q+
  571. # [12:38] * Zakim sees Bert, Bert, ChrisL on the speaker queue
  572. # [12:38] * sylvaing Bert stereo is enabled
  573. # [12:38] <ChrisL> q+ Bert again
  574. # [12:38] * Zakim sees Bert, Bert, ChrisL, again on the speaker queue
  575. # [12:38] <ChrisL> q- Chris
  576. # [12:38] * Zakim sees Bert, Bert, again on the speaker queue
  577. # [12:38] <TabAtkins_> q- again
  578. # [12:38] * Zakim sees Bert, Bert on the speaker queue
  579. # [12:38] <TabAtkins_> q- Bert
  580. # [12:38] * Zakim sees Bert on the speaker queue
  581. # [12:39] <TabAtkins_> [argument about where positioning schemes]
  582. # [12:39] <TabAtkins_> plinss: We agree that we'll address this use-case, and I put it in hakon and the exclusions guys to work out where this goes, offline.
  583. # [12:39] <TabAtkins_> Bert: A different issue, about the dark text on dark background.
  584. # [12:40] <TabAtkins_> Bert: A recent exampe I had was two images. There was text that partly overlaps an image. At the point where it overlaps the image, the text changed color to maintain contrast.
  585. # [12:42] <TabAtkins_> alexmog_: Can we come up with a sufficiently general requirement that, normally, new layout specs shouldn't need to add a ton of text to deal with Exclusions?
  586. # [12:42] <TabAtkins_> TabAtkins_: That would be nice, yes.
  587. # [12:42] <TabAtkins_> <br type=lunch>
  588. # [12:42] * Quits: smfr (smfr@128.93.135.224) (Quit: smfr)
  589. # [12:43] * plinss is now known as plinss_away
  590. # [12:43] * Quits: jet (jet@128.93.134.216) (Quit: jet)
  591. # [12:44] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
  592. # [12:45] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
  593. # [12:45] * Joins: jet (jet@128.93.134.216)
  594. # [12:46] * Quits: florian (florianr@128.93.135.105) (Ping timeout)
  595. # [12:46] * Quits: dbaron (dbaron@128.93.135.77) (Ping timeout)
  596. # [12:47] * Quits: szilles (chatzilla@193.105.139.131) (Ping timeout)
  597. # [12:50] * Quits: TabAtkins_ (tabatkins@74.125.122.49) (Ping timeout)
  598. # [12:52] * Joins: karl (karlcow@128.30.54.58)
  599. # [13:14] * Joins: zenon (5162eb0d@78.129.202.38)
  600. # [13:14] * Parts: zenon (5162eb0d@78.129.202.38)
  601. # [13:21] * Joins: dbaron (dbaron@128.93.135.77)
  602. # [13:52] * Quits: lar_zzz (Adium@79.226.80.18) (Quit: Leaving.)
  603. # [13:53] * sylvaing is now known as sylvaing_away
  604. # [13:56] * Joins: miketaylr (miketaylr@200.188.39.95)
  605. # [14:04] * Quits: miketaylr (miketaylr@200.188.39.95) (Quit: Leaving...)
  606. # [14:11] * sylvaing_away is now known as sylvaing
  607. # [14:18] * Joins: miketaylr (miketaylr@200.188.39.95)
  608. # [14:23] * plinss_away is now known as plinss
  609. # [14:23] * Joins: Rossen (Rossen@128.93.134.230)
  610. # [14:24] * Joins: smfr (smfr@128.93.135.224)
  611. # [14:27] * Joins: glazou (glazou@128.93.135.193)
  612. # [14:27] <fantasai> ScribeNick: fantasai
  613. # [14:27] <fantasai> Topic: Flexbox
  614. # [14:27] * Parts: glazou (glazou@128.93.135.193)
  615. # [14:27] <fantasai> Tab: We have a few issues that are not big or controversial, just Alex and I disagree.
  616. # [14:28] * Joins: glazou (glazou@128.93.135.193)
  617. # [14:28] * Joins: florian (florianr@128.93.135.105)
  618. # [14:28] <alexmog_> http://wiki.csswg.org/spec/css3-flexbox#open-issues
  619. # [14:29] <fantasai> Tab: Two open issues: 18 and 19, and a third one raised by fantasai
  620. # [14:29] <fantasai> Tab: Issue 18
  621. # [14:29] <fantasai> Tab: Right now, in current flexbox as written, auto margins resolve to zero
  622. # [14:29] <fantasai> Tab: if you want to align things, you use flex-pack or flex-align
  623. # [14:29] <fantasai> Tab: In my old proposal auto margins flexed
  624. # [14:29] <fantasai> Tab: Alex prefers having margins flex in cross axis
  625. # [14:30] <fantasai> Tab: And alignment property is falback
  626. # [14:30] <fantasai> Tab: If both are auto, center it. If one is auto, align to other side
  627. # [14:30] <fantasai> Alex: flex-item-align is somewhat redundant with aligning with margins
  628. # [14:31] <fantasai> Alex: Most things that can be done with alignment can be done with flexible margins
  629. # [14:31] <fantasai> Tab: Right. i dropped that idea because of baseline alignment
  630. # [14:31] <fantasai> Alex: If choice is between margin alignment and a separate property, separate property is better because it easier to understand, and it does support baseline alignment, which margins wouldn't
  631. # [14:32] <fantasai> Alex: The concern I have for not doing margin alignment is that in situations where margin alignment works, it is already a well-understood way to align things.
  632. # [14:32] <fantasai> Alex: if you take normal block flow and change to vertical flexbox, you will get the same beahvior: won't get surprises
  633. # [14:32] <fantasai> Alex: There is also not really any contradiction in using margins
  634. # [14:32] * Joins: TabAtkins_ (tabatkins@74.125.122.49)
  635. # [14:32] <fantasai> Alex: Flexbox can insist that auto margins resolve to zero, but it doesn't have to.
  636. # [14:33] <fantasai> Alex: So if both flexbox code and margin code, no special code added, it will just work.
  637. # [14:33] <fantasai> Alex: Setting auto margins to zero seems artificial: no good reason to do it.
  638. # [14:33] <fantasai> Tab: So, auto margins being flexible or zero.
  639. # [14:33] <fantasai> fantasai: Note that zero is the default, so you have to explicitly ask for auto toget the flex behavior.
  640. # [14:34] <fantasai> dbaron: I tend to prefer flexible, though I think auto is confusing a keyword
  641. # [14:34] <fantasai> fantasai: I prefer flex over zero as well
  642. # [14:34] <fantasai> Alex: There was another option that we briefly discussed, that centering and aligning things using flexbox alignment properties does true center and does start-end alignment regardless of overflow
  643. # [14:34] <fantasai> Alex: overflow will still be end alignment
  644. # [14:35] <fantasai> Alex: Margin alignment however should be do what margins do in normal flow> If overflow happens, margin: auto should not result in true centering, should just set those margins to zero and apply whatever alignment
  645. # [14:35] <fantasai> Tab: Basically, use auto-resolution rules from block
  646. # [14:36] <fantasai> Alex: I kindof like that approach even though we have three ways to align an item. They're all consistent. Margins are consistent with margins everywhere, and box properties consistent with each other, and there are no conflicts in flexbox algorithm.
  647. # [14:36] <fantasai> Tab: So we have 2 people for flexible auto margins. Anybody think auto margins should resolve to zero?
  648. # [14:36] <fantasai> Rossen: Why do you want them to be zero?
  649. # [14:36] <fantasai> Tab: Simpler, don't have another way of doing alignment.
  650. # [14:36] <fantasai> Tab: It's not problematic, it's just an extra thing.
  651. # [14:37] <fantasai> dbaron: Is there an existing mechanism that acts on the item individually?
  652. # [14:37] <fantasai> Tab: flex-item-align property
  653. # [14:37] <fantasai> dbaron: I guess I'd lean towards making auto margins zero.
  654. # [14:38] <fantasai> Bert: This looks a lot like vertical-align, so why not use vertical align?
  655. # [14:38] <fantasai> Tab: The name is confusing.
  656. # [14:38] * Joins: miketayl_r (miketaylr@200.188.39.95)
  657. # [14:38] <fantasai> Alex: There is more to it including grid consistency.
  658. # [14:38] * Quits: miketaylr (miketaylr@200.188.39.95) (Connection reset by peer)
  659. # [14:38] <fantasai> Bert: This is specific to flex, but in grid we also have alignment.
  660. # [14:38] <fantasai> Bert: And then we have table alignment.
  661. # [14:39] <fantasai> Bert: If they all use different properties, it might be too much.
  662. # [14:40] * Quits: miketayl_r (miketaylr@200.188.39.95) (Quit: Leaving...)
  663. # [14:40] <fantasai> fantasai: flex-item-align exists because of baseline alignment, right? ... I think we can get away with not having a separate property.
  664. # [14:40] <fantasai> fantasai: need to think about it
  665. # [14:40] <fantasai> Alex: baseline alignment per item isn't particularly useful
  666. # [14:41] <fantasai> Alex: You can set flex-align to baseline, and then use margins to change anything you want not baseline-aligned
  667. # [14:41] <fantasai> Tab: You can't mix stretch and baseline then
  668. # [14:42] <fantasai> ... some confusing discussion ...
  669. # [14:42] <fantasai> Alex: I think the situation of some items being baseline-aligne dand others being stretched is kindof rare.
  670. # [14:42] <fantasai> Alex: So if that's the only reason to have an extra property, it's not worht it.
  671. # [14:42] * fantasai agrees with Alex
  672. # [14:42] <fantasai> Tab: If we use margins for alignment, still have issue of consistency with blocks vs. true centering
  673. # [14:43] <fantasai> fantasai: If you have flex-align, you can do true centering. Just can't mix it with baseline.
  674. # [14:43] <fantasai> Tab: But I want that for [toolbar example?]
  675. # [14:44] <fantasai> fantasai: I think the three of us should get in a room and figure it out.
  676. # [14:44] <fantasai> Tab: Response so far seems to indicate that group has no opinion.
  677. # [14:45] <fantasai> Tab: Next topic. Flex function
  678. # [14:45] <fantasai> Tab: Right now you set flex() on either 'width' or 'height'.
  679. # [14:45] <fantasai> Tab: This has the downside that flex() is only valid width or height, dpeending on orientation of the flexbox.
  680. # [14:45] <fantasai> Alex: Before I would start describing why flex() is bad, I would say that it doesn't have to be a function to begin with.
  681. # [14:46] <fantasai> Tab: Getting to that.
  682. # [14:46] <fantasai> Tab: If you, for whatever reason, change the orientation, you have to switch which property you set it on.
  683. # [14:46] <fantasai> Alex: And you have to store it on both properties.
  684. # [14:47] <fantasai> Tab: Alex instead suggests a separate property that indicates the flex in whichever dimension is appropriate
  685. # [14:47] * Joins: szilles (chatzilla@128.93.135.13)
  686. # [14:47] <fantasai> Alex: I would be fine with either flex property with same value, or flex property that just gives flexibility and use width/height as preferred size
  687. # [14:48] <fantasai> fantasai: Ahhh, I can see that there's a problem either way you go there.
  688. # [14:48] <fantasai> fantasai: If you want preferred width as zero, because you want just flex, then you don't want that stored in 'width' because when you remove flexibility you get something nonsensical
  689. # [14:49] <fantasai> fantasai: But if you set preferred width to your actual preferred width, then you do want that stored in 'width' because when you remove flexibility you want to get that size.
  690. # [14:49] <fantasai> Alex: Other problem with flex function is you can't set flex separately from width or height.
  691. # [14:50] <fantasai> Alex: Seems to be a completely reasonable thing to do
  692. # [14:50] <fantasai> Alex: Everywhere else this would have been a separate property
  693. # [14:50] <fantasai> Alex: Hard to work with the functional notation.
  694. # [14:50] <fantasai> Alex: And you cannot cascade flex separately from preferred size
  695. # [14:50] <fantasai> Alex: And animations would be really difficult to apply to flex function
  696. # [14:51] <fantasai> fantasai: animate from flex 1 to flex 2?
  697. # [14:51] <fantasai> Tab: No problem. But animating from no flex to flex is a problem. But a separate issue than this.
  698. # [14:52] <fantasai> Alex: my preferred solution would be to have a flex property with three values. Fine with having preferred size there.
  699. # [14:52] <fantasai> Alex: For implementation it is redundant.
  700. # [14:52] <fantasai> fantasai: But then you don't get your separate cascading.
  701. # [14:52] <fantasai> Alex: Have sub-properties.
  702. # [14:55] <fantasai> fantasai: I don't think positive and negative flex need to cascade separately. Do you?
  703. # [14:55] <fantasai> Tab: No...
  704. # [14:55] <fantasai> fantasai: I think they should stay one property. If the issue is ease of OM access, that's a separate issue that we need to solve globally.
  705. # [14:56] <fantasai> fantasai: I think the only thing you need is one property with positive and negative flex and a switch for using 'width'/'height' as preferred size or using zero.
  706. # [14:56] <fantasai> nobody else seem to care
  707. # [14:56] <fantasai> discussion of stabilizing spec
  708. # [14:56] <fantasai> dbaron: Would prefer if feature design would stabilize before moving to LC
  709. # [14:57] <fantasai> Alex: These issues are coming up as a result of me implementing the spec.
  710. # [14:57] <fantasai> Alex^: fantasai's condition for moving to LC was that dbaron reviews and approves the spec
  711. # [14:57] <fantasai> Bert: Have a question.
  712. # [14:57] <fantasai> Bert: Flex seems very similar to fr unit in Grid. Can't you use one or the other?
  713. # [14:57] <fantasai> Tab: I think grid is planning to move to flex()
  714. # [14:57] <fantasai> Tab: Can't use fr unit because we need a triplet for flex: preferred size, positive flex, and negative flex.
  715. # [14:58] <fantasai> Tab: fr unit only provides one of those.
  716. # [14:58] <fantasai> Alex: We had that as a unit at some point in Flexbox
  717. # [14:58] * sylvaing thinks of RDF every time he hears 'triplet' #scarred
  718. # [14:58] <fantasai> Tab: But replaced it with e.g. flex(1)
  719. # [14:58] <fantasai> Tab: So Grid pwas planning to move to flex() function. But we no longer have a flex() function anymore.
  720. # [14:58] <fantasai> Alex: Would be weird to remove fr in favor of flex()
  721. # [14:59] <fantasai> Tab: Primary need of flex() function was to establish minimum for flexing
  722. # [14:59] <fantasai> Tab: For grid. You needed a minimum size for columns. But you have the minmax() function
  723. # [14:59] <fantasai> Alex: ...
  724. # [14:59] <fantasai> Tab: Using just the fr unit is too weak, because I want to say this column is ... with minmax() a lot of function of flex() is subsumed
  725. # [14:59] <fantasai> Tab: So fr unit is okay. probably don't need flex function there.
  726. # [15:00] <fantasai> Bert: Does the flex property apply to tables, too? To <col> element for example?
  727. # [15:00] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
  728. # [15:00] <fantasai> fantasai: what happened to the multi-length unit for tables? I remember it was implemented, because I wrote tests for it.
  729. # [15:01] <fantasai> dbaron: I removed it at some point.
  730. # [15:01] <fantasai> dbaron: What the spec said it was supposed to do was same as percentages
  731. # [15:01] <fantasai> Tab: When someone defines table layout, we can figure it out at that point.
  732. # [15:02] <fantasai> [discussion of how undefined table layout is]
  733. # [15:02] <fantasai> Tab: Anyone else have any comments on flexbox?
  734. # [15:04] <fantasai> fantasai: Process is, the three of us get to the point where we can't find any more issues. Then we give it to dbaron. If he can't find any issues, then we go to LC.
  735. # [15:05] <fantasai> Bert: Are you replacing flex() with one or two properties?
  736. # [15:05] <fantasai> Alex: Only one. Because there's only flex in one dimension.
  737. # [15:05] <fantasai> Bert: What about grid?
  738. # [15:06] <fantasai> Alex: ...
  739. # [15:06] <fantasai> Bert: I'm specifically thinking about andrew fedoniouk made
  740. # [15:06] <fantasai> Bert: He did grid and flex together, and came up with a 2D flex model
  741. # [15:06] <fantasai> Tab: You can do a flex grid. But it's not the same thing as the grid layout module that we're talking about.
  742. # [15:07] <fantasai> Alex: Flexbox has a lot of details not applicable to grid.
  743. # [15:07] <fantasai> fantasai: Should think about 2D flexible layout, if we do that we'd need flex in 2 dimensions.
  744. # [15:07] * Zakim excuses himself; his presence no longer seems to be needed
  745. # [15:07] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  746. # [15:07] <fantasai> Tab: Can you link to Andrew's model?
  747. # [15:08] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  748. # [15:08] * Joins: miketaylr (miketaylr@200.188.13.165)
  749. # [15:09] <fantasai> fantasai: Anton and I were suggesting that instead of calling the container a "flexbox" and the children "flexbox items", we should call the the boxes that actually flex "flexboxes" and call the container a "flex container" to be consistent with how we use terminology elsewhere, like blocks and block containers.
  750. # [15:10] <fantasai> fantasai: To make the 'display' value consistent with this, we suggest "display: flex" and "display: inline-flex"
  751. # [15:10] <fantasai> Anton: I'm not won over by 'display: flex', but can't think of anything better.
  752. # [15:10] <dbaron> dbaron: I think making display:flex make something a flexbox container is confusing
  753. # [15:11] <fantasai> Alex: This is the first I hear about this, so let's discuss this first.
  754. # [15:11] <Bert> -> http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm documentation of Andrew Fedoniouk's grid/flex combo (see last para of section 3.5)
  755. # [15:11] * sylvaing renaming -> www-bikeshed mailing list
  756. # [15:12] <fantasai> Topic: Line Module
  757. # [15:15] <fantasai> Steve posts slides
  758. # [15:15] <fantasai> "CSS Line Module Processing Model"
  759. # [15:15] <fantasai> Steve: Sent a message to the mailing list
  760. # [15:15] <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Feb/0238.html
  761. # [15:16] <fantasai> Steve: Basically talking about a processing model for line module
  762. # [15:16] <fantasai> Steve: At November F2F we agreed jdaggett and I would edit Line module
  763. # [15:16] <fantasai> Steve: And to incorporate line grid material into it
  764. # [15:16] <fantasai> Steve: Because line module talks about alignment
  765. # [15:16] <fantasai> Steve: To begin that process, wanted to get agreement on what the processing model is for the line module
  766. # [15:16] <fantasai> Steve: Then have a slide about next steps.
  767. # [15:17] <fantasai> Steve: So this is ot quite the model I put out in the message to the list because dbaron looked at it and comemtned, so I tried to incorporate dbaron's comments.
  768. # [15:17] <fantasai> Steve: Basically, what happens is that with one small exception, you can largely do line breaking and justification prior to do ing alignment
  769. # [15:17] <fantasai> Steve: It's presumed that's what the Text module is describing.
  770. # [15:17] <fantasai> Steve: This is describing alingment within that.
  771. # [15:18] <fantasai> Steve: So once I've got a line, then I have ato adjust eachcomponent of hte line relative to its parent
  772. # [15:18] <fantasai> Steve: based on alignment points, leading, and other things don't want to get into.
  773. # [15:18] <fantasai> Steve: Having done that, then compute height of line, size of line box.
  774. # [15:18] <fantasai> Steve: Two ways of taking that line box and putting it on to the current flow in the block direciton.
  775. # [15:18] <fantasai> Steve: If there is no line grid, no alingment to the line grid, then we just stack the top of the new line box at bottom of previous.
  776. # [15:18] <fantasai> Steve: Relatively straightforward.
  777. # [15:19] <fantasai> Steve: If there is a line grid, then some baseline in the line box is aligne dto some baseline in the line grid.
  778. # [15:19] <fantasai> howcome things the word 'table' in there is confusing
  779. # [15:20] <fantasai> Steve: After I define the line height, I might have things that collide with floats.
  780. # [15:20] <Bert> s/things/thinks/
  781. # [15:20] <Bert> s/aligne dto/aligned to/
  782. # [15:20] <fantasai> Alan: That will require you to recalculate the width
  783. # [15:20] <fantasai> dbaron: If you're laying out lines within a space like this *draws two lines denoting sides of containing block*
  784. # [15:21] <fantasai> dbaron: If you have floats like this *draws narrow float and fat float below it*
  785. # [15:21] <fantasai> dbaron: If the height of the line or its position winds up with the bottom of the line here, you're fine.
  786. # [15:21] <fantasai> dbaron: But if the bottom of the line ends up here *draws line adjacent to fat float* then you have to shorten the line and redo line breaking
  787. # [15:21] <fantasai> dbaron: We should stick to rule that once you shorten it, you don't lengthen it again.
  788. # [15:22] <fantasai> dbaron draws 'this is some <big>TEXT</big>'
  789. # [15:23] <fantasai> dbaron draws this is some onto the line, and TEXT onto a next line. It would fit horizontally, but it would make the line tall enough to intersect the fat float, which would make it no longer fit.
  790. # [15:23] <fantasai> dbaron: Not sure we define what happens in this case.
  791. # [15:24] <fantasai> "Baseline Tables"
  792. # [15:24] <fantasai> Steve: It basically notes that you have different alignment points for differnt scripts. Latin typically alphabetically. Some northern Indic scripts to hanging baseline. Ideographic to ideographic baseline, which is usually the text-after-edge
  793. # [15:24] <Bert> (Re the <big>TEXT</big> example: You might instead make an earlier line a little longer or shorter.)
  794. # [15:25] <fantasai> Steve: So the current vertical-align property doesn't really deal with that, so one of the other tasks the line module took was to come up with a reasonable set of properties that give you control over vertical-align allowing for different baseline tables.
  795. # [15:25] <fantasai> Steve: Few complications to it. In particular, there's a notion called 'dominant baseline', e.g. if you put latin text in Japanese document, the dominant baseline would be ideographic. But Chinese text in English document, dominant baseline is alphabetic.
  796. # [15:25] <fantasai> Steve: Matters because baseline tables are different by font
  797. # [15:26] <fantasai> Steve: The last complication is that I define what alignment is for a given font size and dominant baseline, but there are certain baseliens you can align to that don't come from the font.
  798. # [15:26] <fantasai> Steve: text-to- and text-bottom, which come from leading,
  799. # [15:26] <fantasai> Steve: and bottom and top, which are even messier.
  800. # [15:26] <fantasai> Steve: algorithm in 2.1
  801. # [15:27] <fantasai> Steve: Collection of alignment points I have to deal with, some computed as a result of laying out the lines.
  802. # [15:28] <fantasai> howcome: Statement of different baselines having different baseline tables doesn't make sense to me.
  803. # [15:29] <fantasai> some explanation of bseline tables
  804. # [15:29] <fantasai> most fonts have one baseline table
  805. # [15:29] <fantasai> but some fonts have different baseline tables, you choose a different one depending on your dominant baseline table
  806. # [15:29] <fantasai> s/table//
  807. # [15:29] <fantasai> choice
  808. # [15:29] <fantasai> howcome: CSS shouldn't have to say what hte dominant script is
  809. # [15:30] <fantasai> Steve: there are defaults, and it is automatically specified
  810. # [15:30] <fantasai> jdaggett: That's a detail we don't need to depend on right now.
  811. # [15:30] <fantasai> howcome: If we have to deal with it we have to deal with multiple baselines.
  812. # [15:30] <fantasai> howcome: we use the term 'baseline' in vertical-align, but don't specify which one.
  813. # [15:32] <fantasai> fantasai explains dominant baselines
  814. # [15:32] <fantasai> dbaron: based on what Steve was saying, this is what I imagine is an example
  815. # [15:33] <fantasai> dbaron: You were talking about different sets of baseline tables, I was imagining perhaps Chinese text within English aligning different from English text within Chinese.
  816. # [15:33] <fantasai> dbaron: Here, ideographic baseline matches alphabetic, because alphabetic is dominant
  817. # [15:33] <fantasai> dbaron: Whereas here the Latin is centered between the top and bottom of the ideographic characters because Chinese is dominant and you want to fit everything within the embox
  818. # [15:34] <fantasai> Steve: That's somewhat exaggerated, but yes.
  819. # [15:34] <fantasai> howcome: I'd like to add my use case
  820. # [15:34] <fantasai> howcome: In a multicol element...
  821. # [15:35] <fantasai> Steve: Haven't gotten to line grids yet.
  822. # [15:35] <fantasai> Steve: So that's what baseline tables are about.
  823. # [15:35] <fantasai> Steve: Concerns I have --
  824. # [15:35] <fantasai> Steve: determining top and bottom of baselines. It is in 2.1 except 2.1 is underspecified intentionally
  825. # [15:36] <fantasai> Steve: I see as a goal of this effort is trying to come up with a reasonable definition, because if we don't, we will never be able to do the line grid
  826. # [15:37] <fantasai> jdaggett: It would be good to interact with type design community to [...] to get a consisten platform. Right now we cannot, for a given font, which of several different metrics are given, we currently specified one or the other because there's disagreement about which one should be used.
  827. # [15:37] <fantasai> ChrisL: Platforms disagree on which set of metrics to use.
  828. # [15:37] <fantasai> Steve: Ascenders and descenders are an example
  829. # [15:37] <fantasai> Steve: Last point is, it's been noted that good typography doesn't put half-leading at the top of teh box.
  830. # [15:38] <fantasai> fantasai: or the bottom, if there's a border or anything you can see
  831. # [15:38] <fantasai> jdaggett: So having some way of being able to say you'd like that behavior seems desireable
  832. # [15:39] <fantasai> fantasai: This is complicated by the fact that two paragraphs after each other, if you turn off half leading at the top (and/or bottom) you will have not enough space between the two
  833. # [15:39] <fantasai> dbaron explains this situation further
  834. # [15:39] <fantasai> dbaron: It's in the minutes from the Kyoto meeting.
  835. # [15:40] <dbaron> Basically, that CSS lacks a distinction between blocks that establish frames and blocks that just have line breaks
  836. # [15:40] <fantasai> Steve: So, I treat that as a goal.
  837. # [15:40] <dbaron> and we need the interline spacing at block boundaries for things that aren't frames (with the half-leading at the edges of each of the blocks)
  838. # [15:41] <fantasai> Florian: I think we should deal with the more critical things first.
  839. # [15:41] <dbaron> but that when we're in a block that happens to be at the edge of a frame we don't want that interline spacing
  840. # [15:41] <fantasai> Steve: That's why I treat it as a goal.
  841. # [15:41] <fantasai> Steve: Okay, line grids
  842. # [15:41] <fantasai> Steve: This example is taken from the line grid spec
  843. # [15:41] <fantasai> Steve: Points out what the key goal of the line grid spec is
  844. # [15:41] <fantasai> Steve: If you have, as seen in this multicol, you'd like to ensure that the body text lines up across the columns.
  845. # [15:41] <fantasai> Steve: So you could get interrupted by a figure
  846. # [15:42] <fantasai> Steve: or text in a different size
  847. # [15:42] <fantasai> Steve: But it should resynchronize at the next point
  848. # [15:42] <fantasai> jdaggett: We're using line grids in a couple different contexts.
  849. # [15:42] <fantasai> jdaggett: In this case seems you're really aruging forline boxes are spaced at integral...
  850. # [15:42] <fantasai> howcome: It's a discrete unit.
  851. # [15:42] <fantasai> jdaggett: There's a concept of aligning this thing with other thing.
  852. # [15:42] <fantasai> jdaggett: Multicolumn case is differnet, because you want integral amoutn of space.
  853. # [15:43] * Joins: glenn (gadams@174.29.102.57)
  854. # [15:43] <fantasai> Alan: In the multcol case it's still a grid, it's just something achievable if you can control the other line heights (points at images, headings)
  855. # [15:43] <fantasai> chrisL: The heading, e.g. , is not snapped ot the grid.
  856. # [15:43] <fantasai> Steve: Key thing is within the line grid spec, talks about a constant rhythm.
  857. # [15:44] <fantasai> jdaggett: There are cases where the metrics of the font will tell you that the line box has grown
  858. # [15:44] <fantasai> jdaggett: Want to achieve where things like subscripts leaking out of the linb box but not colliding with anything don't interrupt the rhythm
  859. # [15:45] <fantasai> Steve: Similarly to my topics of concern of alignment, some concerns for line grid
  860. # [15:45] <fantasai> Steve: Idea is that for a container, typically a page, I would define a current font font-size and line-height, and that would dtermine spacing used for that container
  861. # [15:45] <fantasai> Steve: Question is, to what do I align in that?
  862. # [15:45] <fantasai> Steve: I need a table of baselines for each of the slots that I needed
  863. # [15:45] <fantasai> Steve: I can have for example columns where the left column is in English, right colum is in hindi
  864. # [15:46] <fantasai> Steve: They want to align up to the rhythm, but the alignment points are different for each of them
  865. # [15:46] <fantasai> fantasai notes this is already covered by line-grid proposal
  866. # [15:46] <fantasai> ...
  867. # [15:47] <fantasai> Florian: Are you discussing what fantasai proposed in Kyoto? something else? the problem space? how that proposal fits into the probem space?
  868. # [15:47] <fantasai> Steve: hopefully
  869. # [15:47] <fantasai> Steve: So, I left this as a question...
  870. # [15:47] <fantasai> Steve: Can I always just align the dominant baseline in the line, because all other lines are aligned to dominant baseline
  871. # [15:48] <fantasai> Steve: That depends on computing dominant baseline in the line, which you can't do today
  872. # [15:48] <fantasai> Steve: Then, if I go back, if I look at these headings and images (image taken from line-grid)
  873. # [15:48] <fantasai> Steve: If there are chunks that don't align to grid, but want to placed within an integral number of line units
  874. # [15:48] <fantasai> Steve: Question is what do I do with the extra space?
  875. # [15:48] <fantasai> Steve: Could top bottom or center it
  876. # [15:49] <fantasai> Steve: Bert pointed out TeX has a nice feature called glue, similar to flex, which can determine space left above/below
  877. # [15:49] <fantasai> Steve: So certain analogy to flex
  878. # [15:49] <fantasai> howcome: Makes sense, but simple alignment seems like a good idea.
  879. # [15:50] <fantasai> discussion of aligning blocks inside integral number of lines
  880. # [15:50] * Bert opt in... opt out... are images like spam? :-)
  881. # [15:51] <fantasai> Steve: Last point is issue of top-line leading, you might want to define an offset of the lien grid from the top of the container
  882. # [15:51] <fantasai> Steve: So in general, might want to say 'line grid starts here"
  883. # [15:51] <fantasai> Steve: shifts line grid.
  884. # [15:51] <fantasai> steve: though grid is infinite in either direction
  885. # [15:51] <fantasai> Steve: proposed plan
  886. # [15:51] <fantasai> Steve: We have a draft that is seriously out of date
  887. # [15:51] <fantasai> Steve: First step is to take what's there and
  888. # [15:51] <fantasai> Steve: a) update to current template
  889. # [15:51] <fantasai> Steve: b) drop things that are out-of-scope
  890. # [15:52] <fantasai> Steve: e.g. defer drop-caps
  891. # [15:54] <fantasai> ChrisL: If you can do integral number of line grid units, you've solved quite a bit of the drop-caps problem
  892. # [15:54] <fantasai> Steve: Next thing is redo the introduction based on the processing model I just outlined
  893. # [15:54] <fantasai> Steve: Then implement resolution of moving the Line Grid description into this spec
  894. # [15:54] <fantasai> Steve: And then have something to discuss at Hamburg F2F.
  895. # [15:55] <fantasai> discussion of publishing strategy
  896. # [15:56] <fantasai> Steve explains that he tried to send the presentation to the mailing list twice and failed, and that's why it's ot there.
  897. # [15:56] <fantasai> s/ot/not/
  898. # [15:57] <fantasai> Florian: I'm happy this is being worked on.
  899. # [15:57] <dbaron> [ discussion of slide format conversion and avoiding 💩 ]
  900. # [15:58] <fantasai> ChrisL: SVG 1 already has the concept of aligning baselines, and it's a little handwavy. If we can point to this in SVG2 that would be preferable.
  901. # [15:58] <fantasai> dbaron: speaking of SVG and other formats
  902. # [15:59] <fantasai> dbaron: I'm going to attempt to describe what happened, and Chris wil correct me where I'm wrong
  903. # [15:59] <fantasai> dbaron: I think XSL1.0 took the CSS vertical-align property and turned it into a shorthand for 3-4 other properties
  904. # [15:59] <fantasai> dbaron: SVG then took a subset of those properties, but didn't reflect vertical-align as a shorthand
  905. # [15:59] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
  906. # [15:59] <fantasai> dbaron: I think what we want to wind up with is vertical-align as a shorthand.
  907. # [16:00] <fantasai> ChrisL: That's correct except XSL didn't really have shorthands. It had a way of expanding a proeprtiy into traits, which is not quite the same as our shorthand.
  908. # [16:00] * Joins: lhnz (lhnz@188.223.83.48)
  909. # [16:00] <fantasai> dbaron: If we introduce these properties back from svg, would prefer not to have multiple properties with same set of values not shorthand of each other
  910. # [16:01] <fantasai> dbaron: beware there's a bit of hornets nest with some of these properites
  911. # [16:01] * Quits: lhnz (lhnz@188.223.83.48) (Quit: Leaving)
  912. # [16:01] <fantasai> dbaron: we'll probably talk about it again in the future.
  913. # [16:01] <fantasai> Alan: On the www-styel mailing list, there were an arugment that wen tover and over again about what a line box is
  914. # [16:01] * Quits: miketaylr (miketaylr@200.188.13.165) (Connection reset by peer)
  915. # [16:01] * Joins: miketaylr (miketaylr@200.188.13.165)
  916. # [16:01] <glenn> see http://www.w3.org/TR/2006/REC-xsl11-20061205/#shortexpan for more info on XSL shorthands
  917. # [16:01] * Zakim glenn, you typed too many words without commas; I suspect you forgot to start with 'to ...'
  918. # [16:01] <fantasai> Alan: One person said that box that contains glyphs but not the half-leading, and other ...
  919. # [16:02] <fantasai> dbaron: Sure this isn't about inline box? Because if this is about line box, these people had no idea what they were talking about
  920. # [16:02] <fantasai> Alan: What's a line box?
  921. # [16:02] <fantasai> Steve: A box that ocntains the line. COmplex rules that define its top and bottom.
  922. # [16:02] <fantasai> ChrisL: do glyphs always fit in line box?
  923. # [16:02] <fantasai> No.
  924. # [16:02] <fantasai> smfr: ever a gap between line boxes?
  925. # [16:03] <fantasai> No (except for floats and clearance)
  926. # [16:03] <dbaron> My previous research into the messy set of properties that might be a shorthand is https://bugzilla.mozilla.org/show_bug.cgi?id=308338#c21 and my opinion on the way to proceed is https://bugzilla.mozilla.org/show_bug.cgi?id=308338#c28
  927. # [16:03] <fantasai> ChrisL: Does clearance realign to line-grid?
  928. # [16:04] <fantasai> fantasai: My conclusion from last time I looked was that vertical-align should not be a shorthand.
  929. # [16:04] <fantasai> fantasai: vertical-align: baseline should use dominant baseline
  930. # [16:05] <glenn> believes vertical-align should be a shorthand
  931. # [16:05] * Zakim glenn, you typed too many words without commas; I suspect you forgot to start with 'to ...'
  932. # [16:05] <fantasai> fantasai says stuff and doens't minute it again
  933. # [16:06] <fantasai> dbaron: We might not want dominant-baseline to be part of vertical-align, but if we have alignment-shift and alignment-?, those should probably be part of vertical-align
  934. # [16:06] <dbaron> dbaron: I think alignment-adjust and baseline-shift should definitely be subproperties of a vertical-align shorthand if they're included. I don't have a strong opinion on whether dominant-baseline should be in the vertical-align shorthand.
  935. # [16:07] <dbaron> Bert: What happened with vertical aligning of image?
  936. # [16:07] <dbaron> SteveZ: At minimum, we'll add top, bottom, center, and we'll consider adding glue/flex.
  937. # [16:07] <dbaron> <br duration="calc(15 * 60s)" />
  938. # [16:10] * Joins: jdaggett_ (jdaggett@128.93.134.228)
  939. # [16:10] * Quits: jdaggett (jdaggett@128.93.134.228) (Connection reset by peer)
  940. # [16:10] * jdaggett_ is now known as jdaggett
  941. # [16:14] * Joins: ksweeney (ksweeney@63.119.10.10)
  942. # [16:16] * Quits: miketaylr (miketaylr@200.188.13.165) (Ping timeout)
  943. # [16:17] * Joins: Ms2ger (Ms2ger@91.181.83.228)
  944. # [16:21] * Joins: nimbu (Adium@24.18.47.160)
  945. # [16:24] * Joins: Rossen (Rossen@128.93.134.230)
  946. # [16:25] * Parts: ksweeney (ksweeney@63.119.10.10)
  947. # [16:27] <fantasai> Topic: Writing Modes
  948. # [16:28] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
  949. # [16:28] <Bert> scribenick: bert
  950. # [16:29] <Bert> fantasai: Status is: Unicode is working on a proposal. Microsoft is providing data.
  951. # [16:29] <Bert> ... Some data still missing.
  952. # [16:29] <Bert> ... We'll talk to UTC tomorrow.
  953. # [16:29] <Bert> ... Suggest [??] scoping.
  954. # [16:30] <Bert> ... And then... CR is three years, maybe.
  955. # [16:30] <Bert> s/is/in/
  956. # [16:30] <Bert> John: Several modes within vertical
  957. # [16:30] <Bert> ... default mode, stacjking mode
  958. # [16:30] <Bert> ... former for Japanese
  959. # [16:31] <Bert> ... many variations across script.
  960. # [16:31] * fantasai is minuted-out
  961. # [16:31] <Bert> ... Upright in our spec breaks haping.
  962. # [16:31] <Bert> ... but in their proposal it does not.
  963. # [16:31] * Joins: Rossen (Rossen@128.93.134.230)
  964. # [16:31] <Bert> /haping/shaping/
  965. # [16:31] <Bert> [people looking at image, wondering if it wrong]
  966. # [16:32] <Bert> David: [explains the hebrew image]
  967. # [16:32] <Bert> John: Controversy is about bidi, flipping
  968. # [16:32] <Bert> ... In their model, some punct always rotates.
  969. # [16:33] <Bert> ... Certain things are not going to stack in the stacking mode.
  970. # [16:33] <Bert> David: Is this PDF available?
  971. # [16:33] <Bert> John: Only private mail so far.
  972. # [16:33] <Bert> Sylvain: I can ask for more copies.
  973. # [16:34] <Bert> John: Slightly diff orientations between what upright-right and upright.
  974. # [16:34] <Bert> ... Until recently we had a proposal with default upright-right.
  975. # [16:34] * sylvaing will check wether we can at least share the table....
  976. # [16:34] <Bert> ... Different things happen with different characters, depending on whether they rotate in certain conditions.
  977. # [16:35] <Bert> ... This new proposal sets it up differently. Som echaracters are automatically rotated or not.
  978. # [16:35] <Bert> fantasai: It wa spart if our original proposal as well.
  979. # [16:35] * Quits: glenn (gadams@174.29.102.57) (Ping timeout)
  980. # [16:35] <Bert> [John and Elika working our what proposal said what]
  981. # [16:35] <Bert> Florian: So, no way for author to set final orientation?
  982. # [16:36] <Bert> John: Exactly.
  983. # [16:36] <Bert> Fantasai: We didn't have override aoriginally either.
  984. # [16:36] <Bert> Florian: You want an 'override: force'?
  985. # [16:36] <Bert> John: Some symbols, arrows, are going to auto-rotate, isn't it, Elika?
  986. # [16:37] <Bert> fantasai: No, everything upright, except for certain for which we have no use-case (brackets and dashes)
  987. # [16:37] <Bert> ... We have no use-case for forcing everyhting uprifght.
  988. # [16:37] <Bert> ... Only for forcing most things iupright.
  989. # [16:37] <Bert> ... We could add a force-upright.
  990. # [16:37] <Bert> ... But need a use-case first.
  991. # [16:38] <Bert> John: Are the sideways forcing everything sideways?
  992. # [16:38] <Bert> fantasai: Yes.
  993. # [16:38] <Bert> florian: So we are not pevented from adding an override later.
  994. # [16:39] <Bert> John: Hiroglyphs may mirror.
  995. # [16:39] <Bert> fantasai: : They face the start of the line.
  996. # [16:39] <Bert> ... Maybe we don't need to implement that, but it is correct behavior.
  997. # [16:39] <Bert> Florian: Chinese readers reading hieroglyphs
  998. # [16:39] <Bert> ... Will they recognize the hieroglyphs?
  999. # [16:40] <Bert> fantasai: People reading hiero will know about this...
  1000. # [16:40] <dbaron> Table with Latin1, 日本, עִבְרִית, العربية, ᠮᠣᠨᠭᠭᠣᠯ, !@#, ([-]), and some hieroglyphs
  1001. # [16:40] <Bert> Steve: It is by cluster, not by charater?
  1002. # [16:40] <Bert> fantasai: Yes.
  1003. # [16:40] * ChrisL has to see dbaron's line
  1004. # [16:40] <Bert> ... We have a minimum definition that says you use a grapheme cluster.
  1005. # [16:40] <ChrisL> rrsagent, make minutes
  1006. # [16:40] <RRSAgent> I have made the request to generate http://www.w3.org/2012/02/08-css-minutes.html ChrisL
  1007. # [16:41] <Bert> Steve: I heard it is not exactly the right term.
  1008. # [16:41] <Bert> fantasai: It is the closest that applies.
  1009. # [16:41] <Bert> ... We have some text about other traditions in the text.
  1010. # [16:41] <Bert> ... We asked for more details, but nobody is giving us any.
  1011. # [16:41] <Bert> Steve: So it is not a character property.
  1012. # [16:42] <Bert> ... You take chunks of text and treat and place them.
  1013. # [16:42] <Bert> John: When you have cluserts, with base and comb, char, then rotation is determined by base char.
  1014. # [16:42] * Joins: glenn (gadams@71.218.121.85)
  1015. # [16:43] <Bert> Steve: If you have a hyphenated comination (or apostr), do I want ... or... [drawings]
  1016. # [16:44] <Bert> .. Can the apostroph be below the letter in verticla stacking, or always attached on the right of the letter ("l'")
  1017. # [16:44] <Bert> glazou: Attached.
  1018. # [16:44] <dbaron> Table with Latin1, 日本㊥①, עִבְרִית‎, العربية, ᠮᠣᠨᠭᠭᠣᠯ, !@#, ([-]), and some hieroglyphs
  1019. # [16:45] <Bert> ACTION sylvain: try to get copies of the proposal from UTC for the WG.
  1020. # [16:45] * RRSAgent records action 4
  1021. # [16:45] * trackbot noticed an ACTION. Trying to create it.
  1022. # [16:45] <trackbot> Sorry, couldn't find user - sylvain
  1023. # [16:45] <Bert> John: Koji, Elika and I eveloved our knowldege. We have more details now.
  1024. # [16:46] <Bert> ... We could come up on proposal based on Unicode ranges and proeprties that covers 95%.
  1025. # [16:46] <Bert> ... But then with new Unciode version we would have to revise.
  1026. # [16:46] <Bert> ... So it;s better if Unciode defines a proeprty.
  1027. # [16:46] <Bert> ... Then we don't have to define anything.
  1028. # [16:46] <dbaron> s/eveloved/evolved/
  1029. # [16:46] <dbaron> s/Unciode/Unicode/
  1030. # [16:47] <Bert> ... Previous proposal from Adobe with upright and sideways. Now UTC has more detailed proposal.
  1031. # [16:47] <Bert> fantasai: Eric (Unicode) ...
  1032. # [16:47] <Bert> John: Vertical Japanese in Eric's mind has orientation, but also spcing aspects.
  1033. # [16:48] <Bert> ... I think it is not good to mix the aspects.
  1034. # [16:48] <Bert> Steve: He changed recently. He observed
  1035. # [16:48] <Bert> ... there are two things that need char classes.
  1036. # [16:48] <Bert> ... (1) rotated ort not (2) what spaces applies in each context.
  1037. # [16:48] <Bert> ... He wanted one set of char classes.
  1038. # [16:49] <Bert> ... That could define both.
  1039. # [16:49] * Quits: jet (jet@128.93.134.216) (Quit: jet)
  1040. # [16:49] <Bert> ... One set that solves both problems.
  1041. # [16:49] <Bert> ... But since then he concluded that upright is not a character-level property.
  1042. # [16:49] * Quits: glenn (gadams@71.218.121.85) (Ping timeout)
  1043. # [16:49] <Bert> ... Sometimes cluster.
  1044. # [16:49] <Bert> ... (He didn't send that proposal yet.)
  1045. # [16:50] <Bert> .. . A mode in text combine that does thew groupin gin vertical stacking case.
  1046. # [16:50] <Bert> ... More TCY and" IJ" in Dutch kind of thing.
  1047. # [16:50] <Bert> John: So none of use heard this before.
  1048. # [16:50] <dbaron> s/use/us/
  1049. # [16:50] <Bert> ... We'll find out tomorrow.
  1050. # [16:51] <Bert> ... We'll join UTC call tomorrow,
  1051. # [16:51] <Bert> ... OpenType doensnt' have a clear nodel what features are turned on in vertical.
  1052. # [16:52] <Bert> ... It will probabluy need to involve Microsoft as well.
  1053. # [16:52] <Bert> Steve: In general you do not know whicg feeatures apply,
  1054. # [16:52] <Bert> John: For each script you know which apply.
  1055. # [16:52] <Bert> ... But in vertical text for those same script it is not clear.
  1056. # [16:52] <Bert> ... We need implementer input.
  1057. # [16:53] <Bert> ... Final glyph in vertical can be a ligature, or not. not clear.
  1058. # [16:53] <Bert> fantasai: Might also be a verticla ligature.
  1059. # [16:53] <Bert> John: Some trickery.
  1060. # [16:53] <fantasai> s/be/have/
  1061. # [16:53] <fantasai> s/verticla/vertical/
  1062. # [16:53] <fantasai> s/whicg/which/
  1063. # [16:53] <Bert> ... Font has vertical ligatures and they are turned on sometimes.
  1064. # [16:54] <Bert> ... Uses a dummy glyph.
  1065. # [16:54] <Bert> ... We need to figure out what UA does with OpenType.
  1066. # [16:54] <Bert> Fantasai: It needs a VLIG (vertical ligature)...
  1067. # [16:54] <Bert> Koji: So you are joining the OpenType standardization now, too? :-)
  1068. # [16:56] * Joins: glenn (gadams@174.29.122.35)
  1069. # [16:58] <Bert> Topic: Fragmentation
  1070. # [16:58] <fantasai> http://dev.w3.org/cvsweb/csswg/css3-break/
  1071. # [16:58] <Bert> fantasai: We have a draft, should we publish it?
  1072. # [16:58] <Bert> ... There are no new features in this draft.
  1073. # [16:59] <smfr> http://dev.w3.org/csswg/css3-break/
  1074. # [16:59] <fantasai> http://dev.w3.org/csswg/css3-break/
  1075. # [16:59] <Bert> ... It takes the various break-* properties, made tables and added explanations.
  1076. # [16:59] <Bert> Bert: If there is indeed noting new, then I'm OK.
  1077. # [17:00] <Bert> Alex: Do you plan to put anything else in the spec?
  1078. # [17:00] <Bert> ... BEhavior of ab. pos acorss pages, floats across pages?
  1079. # [17:00] <Bert> fantasai: Varying page widths is in the spec.
  1080. # [17:00] <Bert> Anton: Tetx comes from which other specs?
  1081. # [17:00] <Bert> fantasai: CSS 2.1, multicol, paged media...
  1082. # [17:00] <Bert> florian: Dependencies?
  1083. # [17:01] <Bert> fantasai: Only CSS 2.1
  1084. # [17:01] <Bert> Alex: Which specs should define paged abs. pos?
  1085. # [17:01] <Bert> fantasai: Probably Positioning.
  1086. # [17:01] * Quits: glenn (gadams@174.29.122.35) (Ping timeout)
  1087. # [17:01] <Bert> ... Probably let Frag,emtation deal with notmal block layout and then other modules can refer to this.
  1088. # [17:02] <Bert> Alex: It assumes that you *can* actually page abs.pos.
  1089. # [17:02] <Bert> ... It seems it belongs more in this spec.
  1090. # [17:02] <Bert> ... Spec should say what it claims to cover in the future.
  1091. # [17:02] * glazou FWIW http://glazman.org/tmp/Vapostrophe.xhtml
  1092. # [17:03] <Bert> ... Related to call for exclusions.
  1093. # [17:03] <Bert> ... So good to have it there right away.
  1094. # [17:03] <Bert> Peter: We are never presented from adding a chapter later.
  1095. # [17:03] <Bert> Alex: Yes, but scope is good to know from the start.
  1096. # [17:03] <glazou> s/presented/prevented
  1097. # [17:03] <Bert> Anton: This will come up all the time, with so many specs and dependencies.
  1098. # [17:04] <Bert> ... In some sense we want hte framework here, but whether paging happens at all is defined in all other modules.
  1099. # [17:04] <Bert> ... This is lower-level framework.
  1100. # [17:04] <Bert> fantasai: Animations is an example.
  1101. # [17:04] <Bert> ... Each spec defines whether or not a proeprty animates, w/o defining how
  1102. # [17:05] <Bert> ... Here we have a set of possible breakpoints in Fragmentation.
  1103. # [17:05] <Bert> ... Other specs can add points to class-one breakpoint.
  1104. # [17:05] <Bert> ... Tables module might add rows of a table to that,
  1105. # [17:05] <Bert> ... Flexbox might add space between flaxboxes to that.
  1106. # [17:05] <Bert> Alex: What is status of Tables?
  1107. # [17:06] <Bert> fantasai: It doesn't currently exists.
  1108. # [17:06] <Bert> ... But Fragmentation refers to CSS 2.1 for tables and defines breaking for it.
  1109. # [17:06] <Bert> .
  1110. # [17:06] <Bert> ... Block layout is basic and needs to be covered here,
  1111. # [17:07] <Bert> Alex: I see no reason to not publish, but I want discussion about scope.
  1112. # [17:07] <Bert> ... FPWD should have (in ToC) alostof things intended to be covered.
  1113. # [17:07] <Bert> s/alostof/ a lst of/
  1114. # [17:07] <Bert> fantasai: We can add text about relations to other specs.
  1115. # [17:08] <fantasai> ACTION fantasai: Clarify in css3-break what other specs are supposed to say about fragmentation
  1116. # [17:08] * trackbot noticed an ACTION. Trying to create it.
  1117. # [17:08] * RRSAgent records action 5
  1118. # [17:08] <trackbot> Created ACTION-445 - Clarify in css3-break what other specs are supposed to say about fragmentation [on Elika Etemad - due 2012-02-15].
  1119. # [17:08] * Joins: glenn (gadams@174.29.117.109)
  1120. # [17:08] <Bert> Rossen: Each layout defines its own fragmentation.
  1121. # [17:08] <Bert> RESOLVED: publish FPWD of Fragmentation.
  1122. # [17:09] <Bert> Alex: I expected a combination of CSS 2.1 and Paged Media should be enough to define 2.1 layout completely for pagination.
  1123. # [17:10] <Bert> ... To understand exactly how 2.1 paginates, you need 2.1, Paged Media and Fragmentation.
  1124. # [17:10] <Bert> fantasai: Not Pgaed Media.
  1125. # [17:10] <Bert> Alex. OK.
  1126. # [17:10] <Bert> ... For other specs, I would need to figure out what th elist is,
  1127. # [17:10] <dbaron> Whiteboard photos from today: http://lists.w3.org/Archives/Public/www-archive/2012Feb/0012.html
  1128. # [17:11] <Bert> fantasai: The CSS modules should define their pagination, ad can refer to Fragmentation and themselves to the hooks in that spec.
  1129. # [17:11] <Bert> s/and/and add/
  1130. # [17:12] <Bert> ... All other specs will say you are allowed to break here and here with respect to a possible break points.
  1131. # [17:12] <Bert> ... Positioning may have to say little bit more.
  1132. # [17:12] <Bert> fantasai: There is an issue with two different propsoed behaviors for floats.
  1133. # [17:13] <Bert> ... Option A and otption B.
  1134. # [17:13] <Bert> ... But we don't have to pick one today, can do it later. Can publish both for now.
  1135. # [17:13] <Bert> ... Heard from Alex, but not from others. Need to publish first.
  1136. # [17:14] <Bert> ATION fantasai to add pictures to Fragmentation
  1137. # [17:14] <Bert> ACTION fantasai to add pictures to Fragmentation
  1138. # [17:14] * trackbot noticed an ACTION. Trying to create it.
  1139. # [17:14] <trackbot> Created ACTION-446 - Add pictures to Fragmentation [on Elika Etemad - due 2012-02-15].
  1140. # [17:14] <Bert> Topic: Tranforms
  1141. # [17:14] <Bert> s/Tranforms/Transforms/
  1142. # [17:15] <smfr> http://lists.w3.org/Archives/Public/www-style/2009Oct/0360.html
  1143. # [17:15] <Bert> David: [Draws on whiteboard]
  1144. # [17:15] <Bert> ... Related to matrix units.
  1145. # [17:15] <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15628
  1146. # [17:16] <Bert> ... 2D transform uses matrices like this [draws]
  1147. # [17:16] <Bert> ... (a,b,c,d,e,f)
  1148. # [17:16] <Bert> ... Multiply this by (x_in, y_in) and it gives (x_out,y_out)
  1149. # [17:17] <Bert> ... Some have units, some are unitless.
  1150. # [17:17] <Bert> ... Current draft says translate takes length arguments.
  1151. # [17:17] * Joins: jet (jet@82.123.138.167)
  1152. # [17:18] <Bert> ... But matrix uses px in translation part.
  1153. # [17:18] <Bert> ... Nowehere else inj CSS do we say that unitless means px.
  1154. # [17:18] <Bert> ... We could add units to e and f.
  1155. # [17:18] <Bert> ... But then problem with 3D.
  1156. # [17:19] <Bert> ... 3D matrix has two arguments with px, one with a z-index, and some with "px/z-index"
  1157. # [17:20] <Bert> ... And some with 1/px.
  1158. # [17:20] <Bert> ... So easy enough to fix for 2D matrix, but what then for 3D matrix?
  1159. # [17:20] <Bert> ... Gecko implemented at first with e and f requiring a unit.
  1160. # [17:21] <Bert> ... FF10 allows unitless, but accepts units, too,
  1161. # [17:21] <Bert> Chris: That sounds like a good way,
  1162. # [17:21] <Bert> David: But it tells users that px is good to use, which we so far tried to avoid.
  1163. # [17:22] <Bert> glazou: But nobody will ever use a matrix.
  1164. # [17:22] <Bert> ... Will decompose into rotate, translate, etc.
  1165. # [17:22] <Bert> Alex: But stuill more peopla understand matrix than margin collapsing :-)
  1166. # [17:22] <fantasai> | a c e | | x | | X |
  1167. # [17:22] <fantasai> | b d f | | y | = | Y |
  1168. # [17:22] <fantasai> | 0 0 1 | | 1 | | 1 |
  1169. # [17:22] <fantasai> matrix(a,b,c,d,e,f)
  1170. # [17:22] <fantasai> translate(5px, 10px)
  1171. # [17:22] <fantasai> matrix(1,0,1,1,5,10) ^ ^^ ~ pixels implied
  1172. # [17:22] <fantasai> 3D has 16-value matrix with units of px and 1/px and z and 1/z mixed in
  1173. # [17:23] <Bert> glazou: I want DOM to output a decomposed value, not a matrix.
  1174. # [17:23] <smfr> q+
  1175. # [17:23] * Zakim sees smfr on the speaker queue
  1176. # [17:23] <Bert> ... Don't care whether it is with or without units.
  1177. # [17:23] <Bert> Chris: What is the decomposition? Arbitrary sequence that is equivalent?
  1178. # [17:23] <Bert> Glazou: as long as it is editable.
  1179. # [17:23] <Bert> Simon: Return what was set on the element.
  1180. # [17:24] <Bert> ... Preserved.
  1181. # [17:24] <Bert> glazou: Preserved is perfect, but a minimal decompostion is fine.
  1182. # [17:24] <fantasai> | - - len/z len |
  1183. # [17:24] <fantasai> | - - len/z len |
  1184. # [17:24] <fantasai> | z/len z/len - z |
  1185. # [17:24] <fantasai> | 1/len 1/len 1/z - |
  1186. # [17:25] <Bert> ... I don't care about the units on the translation part.
  1187. # [17:25] <Bert> Chris: If you use multiple length in multiple translations, will they be recomposed into px?
  1188. # [17:25] <Bert> Simon: Yes
  1189. # [17:25] <Bert> David: the units will be translated to underlying units, for screen that is generally px.
  1190. # [17:26] <Bert> Tab: Internally it is something liek 1/16 px.
  1191. # [17:26] <Bert> David: It seems we have to allow unitless, shoudl we also allow lengths?
  1192. # [17:26] <Bert> glazou: If you really want 2em, you can just add a translate().
  1193. # [17:27] <Bert> Tab: Issue was computed value.
  1194. # [17:27] <Bert> Simon: Animation...
  1195. # [17:27] <Bert> David: I think animation works on matrices.
  1196. # [17:28] <Bert> Chris: Some people working with 3D in HTML5 *do* want matrices.
  1197. # [17:28] <Bert> glazou: Yes, but you don't have to put the 2em in the matrix.
  1198. # [17:28] <Bert> David: So people seem leaning towards no units in matrix?
  1199. # [17:29] <Bert> Howcome: ...
  1200. # [17:29] <Bert> Tab: I all invertable matrices are decomposable,
  1201. # [17:29] <Bert> ... do the others do anything important?
  1202. # [17:29] <Bert> several: probably not.
  1203. # [17:30] <Bert> glazou: When we remove the commas from the matrix (as proposed earleir), then we can add units.
  1204. # [17:30] <Bert> David: I first raised this 2.5 years ago.
  1205. # [17:30] <Bert> ... At this point I'm ago to leave it at unitless.
  1206. # [17:31] <Bert> Alex: What if somebody need 1/inch?
  1207. # [17:31] <Bert> David: Since in = 96px, use 1/96px
  1208. # [17:31] * glazou if somebody needs 1/inch, that will sound like viagra spam and will be trashed :-p
  1209. # [17:32] <Bert> Simon: matrix API cannot always resolve lengths, if you are not using it on a current element.
  1210. # [17:32] <Bert> Florian: Could have a single unit that applies to all of the matrix.
  1211. # [17:32] <Bert> David: Don't really want to do that...
  1212. # [17:33] <Bert> Glazou: Why not unitless?
  1213. # [17:33] <Bert> David: Consistent with general rule in CSS that there are no unitless lengths, so as not to tell people to use px.
  1214. # [17:34] <Bert> Vincent: SVG... unitless...
  1215. # [17:34] * Quits: glenn (gadams@174.29.117.109) (Ping timeout)
  1216. # [17:34] <Bert> ... Transform is currently an attribute in SVG, not a property.
  1217. # [17:34] <Bert> David: CSS things used inside SVG allow unitless.
  1218. # [17:35] <Bert> Vincent: In an attribute I can use something that I cannot copy and paste to a CSS property.
  1219. # [17:35] <Bert> David: That is true of most attributes.
  1220. # [17:35] <Bert> Chris: Fonts, e.g.
  1221. # [17:35] <Bert> Peter: So we conclude no units on matrix?
  1222. # [17:36] <Bert> Chris: Also need a more efficient representation in JS, not a string, but a set of numbers.
  1223. # [17:36] <Bert> Peter: We could pick any unit.
  1224. # [17:37] <Bert> RESOLVED: no change from current spec.
  1225. # [17:37] <Bert> David: I hope spec is clear that they are px...
  1226. # [17:37] <Bert> Howcome: Add some language to warn that px aren't special, only used here.
  1227. # [17:38] <Bert> RESOLVED: matrix and matrix-3d continue to take unitless numbers, where they need units, they are implicitly px or 1/px.
  1228. # [17:40] <Bert> s/RESOLVED: no change from current spec.//
  1229. # [17:40] <Bert> David: We should not merge 2d and 3d.
  1230. # [17:40] <Bert> ... Progress on 2d is more than 3d.
  1231. # [17:41] <Bert> glazou: What if 2d reached CR before 3d, what happens to the prefix of 'transform'?
  1232. # [17:41] <Bert> David: Then we need a prefix on the 3d functions.
  1233. # [17:41] <Bert> Simon: We will accept... prefixed... unprefixed....
  1234. # [17:41] <Bert> Glazou: nightmare.
  1235. # [17:41] <Bert> ... You cannot remove prefixes on 2d then.
  1236. # [17:42] <Bert> Peter: We can take 2d to CR and decide to drop prefixes from 3d.
  1237. # [17:42] <Bert> Simon: 3d is a lot less interoperable.
  1238. # [17:42] <Bert> David: Don't know the details of the issues.
  1239. # [17:42] <Bert> ... There are some tests being made.
  1240. # [17:43] <Bert> Pater: They are not in our system, need different formats.
  1241. # [17:43] <Bert> s/Pater/Peter/
  1242. # [17:43] * Joins: glenn (gadams@174.29.104.71)
  1243. # [17:43] <Bert> ... Just put them in the submitted directory and Sheperd will tell you what is wrong.
  1244. # [17:44] <Bert> ... Put them there as soon as you want people to review them.
  1245. # [17:44] <Bert> Vincent: Merging with SVG, predicatble model important.
  1246. # [17:44] <Bert> ... Ediotrial issues, wher eis work going to happen?
  1247. # [17:45] <Bert> ... One spec to CR, then a merged spec...
  1248. # [17:45] <Bert> ... I don't know a solution.
  1249. # [17:45] <Bert> David: I don't want 2d to wait on SVG stuff.
  1250. # [17:45] <Bert> ... 2d is not going to change.
  1251. # [17:45] <Bert> ... There miht be more variant syntaxes, but probably not more.
  1252. # [17:46] <Bert> Sylvain: We rejected px already because we cant change it anymore.
  1253. # [17:46] <Bert> ... So bigger changes not possoible either.
  1254. # [17:46] <Bert> Chris: A bit strange though. We promise to work together and then publish one spec anyway.
  1255. # [17:47] <Bert> ... SVG also has had transforms for years.
  1256. # [17:47] <Bert> ... Probably only need to work on the wording, where it only makes sense for SVG or CSS.
  1257. # [17:47] <Bert> ... Coordination is good now, let's not put it at risk.
  1258. # [17:48] <Bert> Simon: Combined spec has a lot on 3d now.
  1259. # [17:48] <Bert> Tab: So we say we cannot change transpfrms 2d anymore, we rejected that argument this morning, what is different?
  1260. # [17:49] <Bert> Peter: What is going to change, the syntax or the functionality?
  1261. # [17:49] <Bert> ... Arument is that 2d transform has both fixed now, other specs not.
  1262. # [17:50] <Bert> Sylvain: Not sure we are as ready to publish 2d as we thoughtt. We are thinking of some new functionality already.
  1263. # [17:51] <Bert> ... Stacking and fixed positioning issues.
  1264. # [17:51] <Bert> Tab: That is not syntax issue.
  1265. # [17:51] <Bert> David: Containing block.
  1266. # [17:51] <Bert> ... Have to walk through the subtree looking for fixed pos. elts.
  1267. # [17:52] <Bert> Vincent: We decided I think to merge, we need to discuss with FX group.
  1268. # [17:52] <Bert> Peter: YEs, but we made the caveat that we shouldn't delay CR.
  1269. # [17:52] <Bert> Sylvain: We can prioritize 2d.
  1270. # [17:53] <Bert> Peter: Real-world need for 2d.
  1271. # [17:53] <Bert> Chris: yes, but why did we make a merged spec since 9+ months, and now we are ignoring it.
  1272. # [17:53] <Bert> ... Can't we publish that spec?
  1273. # [17:54] <Bert> Vincent: Can we go over the issues first in the merged spec. Brining 3d to SVG is another topic.
  1274. # [17:55] <Bert> ... Then go over the list, and at leats have one consisytent model.
  1275. # [17:55] <Bert> Sylvain: Have a document by next ftf.
  1276. # [17:55] <Bert> Simon: Still the problem of dropping prefixes.
  1277. # [17:56] <Bert> ... I think we can drop prefixes early.
  1278. # [17:56] <Bert> Vincent: We shpoild at leats have a review of the issues, then we know if the issues are maybe minor.
  1279. # [17:56] <Bert> Simon: syntax issues probably minor.
  1280. # [17:56] <Bert> ... Transform origin is harder.
  1281. # [17:57] <Bert> Chris: Not clear that SVG is holding that up.
  1282. # [17:57] * Quits: glenn (gadams@174.29.104.71) (Ping timeout)
  1283. # [17:57] <Bert> Simon: Should a test suite have SVG tests, and should UAs pass SVG before the spec can advance?
  1284. # [17:58] <Bert> David: A spec is not free. The spec is not done. It is holding things up, I think.
  1285. # [17:58] <Bert> Chris: A UA can implement only CSS or only SVG.
  1286. # [17:58] <Bert> Simon: Conformance classes. Four: {2d,3d}x{CSS,SVG}
  1287. # [17:59] <Bert> Chris: SVG has had transforms since 1998, we aren't strating from scratch.
  1288. # [17:59] <Bert> ... Mixing HTML and SVG and CSS is not rare, it is being used more and more.
  1289. # [17:59] <Bert> Peter: What is the path forward?
  1290. # [18:00] <Bert> Vincent: I like to have time to go over the issues with the W. There is not really SVG vs CSS. And we do't want two solutions in the end.
  1291. # [18:01] <Bert> ... Dirk is working fulltime on transforms, listing the issues and looing at ipls.
  1292. # [18:01] <Bert> ... We have them on a wiki, we can discuss tjem in two weeks.
  1293. # [18:01] <Bert> ... Would be good to understand first what the implciations are.
  1294. # [18:01] <Bert> ... I propose we look at the issues at the telcon.
  1295. # [18:02] <Bert> Simon: wiki or bugzilla?
  1296. # [18:02] <Bert> Vincent: wiki
  1297. # [18:02] <Bert> Simon: Move to bugzilla?
  1298. # [18:02] <Bert> Vincent: I think everything is there already, the wiki is to support.
  1299. # [18:02] <Bert> fantasai: So we have two unmaintaned specs and obe merged spec that is maintained?
  1300. # [18:03] <Bert> Simon: Yes?
  1301. # [18:03] <Bert> fantasai: Are all issues in the issue slist?
  1302. # [18:03] <Bert> Vincent: Yes, should be.
  1303. # [18:03] <Bert> fantasai: How many? How long would going thorugh them take?
  1304. # [18:03] <Bert> Vincent: 2d issues are tractable, 3d issues are bigger, more uncertain
  1305. # [18:03] <Bert> Simon: 48 issues, about 1/3 are 2d.
  1306. # [18:04] * Joins: glenn (gadams@71.218.125.44)
  1307. # [18:04] <Bert> fantasai: In general, we just cut unstable features and continue the rest.
  1308. # [18:04] <Bert> ... Seems to me we should cut 3d, and make that the next level of the module.
  1309. # [18:05] <Bert> Simon: That doens't help with dropping prefixes, some keywords are shared in 2d and 3d.
  1310. # [18:05] * Joins: miketaylr (miketaylr@201.63.86.140)
  1311. # [18:05] <Bert> ... Although might not be so bad in practice to have prefixed 3d functions...
  1312. # [18:05] <fantasai> s/some keywords/some properties/
  1313. # [18:06] <Bert> ... Unprefixed property would accept only 2d funtsions, prefixed proeprty would accept 2d and 3d both.
  1314. # [18:06] <Bert> ... Potential breakage, but risk is fairly low.
  1315. # [18:06] <Bert> Simon: Need input from other implementers.
  1316. # [18:07] <Bert> Vincent: We can go over 2d issues, and establish at leats the status of the 3d ones. Then make decision in a month.
  1317. # [18:07] <Bert> Sylvainb: I'd rather go to whole list of issues first.
  1318. # [18:07] <dbaron> s/go to/go through/
  1319. # [18:07] <Bert> s/Sylvainb/Sylvain/
  1320. # [18:08] <Bert> Vincent: Dirk will categorize issues.
  1321. # [18:08] * Quits: jdaggett (jdaggett@128.93.134.228) (Quit: jdaggett)
  1322. # [18:08] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
  1323. # [18:08] * Quits: dbaron (dbaron@128.93.135.77) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1324. # [18:09] <Bert> fantasai: We didn't talk about Text. We have an issue on text-transform, but are there any others that would prevent a LC?
  1325. # [18:09] <Bert> John: There are a couple on text-transform alone.
  1326. # [18:09] * Quits: antonp (805d879d@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
  1327. # [18:09] <Bert> Steve: I dont know, I haven't looked yet.
  1328. # [18:10] * Quits: florian (florianr@128.93.135.105) (Ping timeout)
  1329. # [18:10] * Quits: kojiishi (kojiishi@128.93.135.158) (Quit: Leaving...)
  1330. # [18:10] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
  1331. # [18:10] * Quits: smfr (smfr@128.93.135.224) (Quit: smfr)
  1332. # [18:11] <Bert> ADJOURNED.
  1333. # [18:11] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
  1334. # [18:12] * Quits: glenn (gadams@71.218.125.44) (Ping timeout)
  1335. # [18:12] * Quits: szilles (chatzilla@128.93.135.13) (Ping timeout)
  1336. # [18:13] * plinss is now known as plinss_away
  1337. # [18:13] * sylvaing is now known as sylvaing_away
  1338. # [18:15] * Quits: TabAtkins_ (tabatkins@74.125.122.49) (Ping timeout)
  1339. # [18:16] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  1340. # [18:18] * Quits: astearns (qw3birc@128.30.52.28) (Ping timeout)
  1341. # [18:19] * Joins: glenn (gadams@174.29.101.250)
  1342. # [18:25] * Quits: glenn (gadams@174.29.101.250) (Ping timeout)
  1343. # [18:32] * Joins: glenn (gadams@174.29.103.95)
  1344. # [18:38] * Quits: drublic (drublic@77.2.157.148) (Ping timeout)
  1345. # [18:50] * Quits: miketaylr (miketaylr@201.63.86.140) (Quit: Leaving...)
  1346. # [18:55] * Joins: glazou (glazou@80.12.80.112)
  1347. # [18:56] * Quits: glazou (glazou@80.12.80.112) (Quit: glazou)
  1348. # [18:57] * Joins: szilles (chatzilla@62.50.199.254)
  1349. # [19:00] * Joins: glazou (glazou@80.12.80.112)
  1350. # [19:00] * Quits: glazou (glazou@80.12.80.112) (Quit: glazou)
  1351. # [19:06] * Joins: drublic (drublic@95.115.4.190)
  1352. # [19:08] * Joins: jdaggett (jdaggett@80.12.80.112)
  1353. # [19:09] * Quits: jdaggett (jdaggett@80.12.80.112) (Quit: jdaggett)
  1354. # [19:13] * plinss_away is now known as plinss
  1355. # [19:23] * Quits: jet (jet@82.123.138.167) (Quit: jet)
  1356. # [19:34] * Quits: Ms2ger (Ms2ger@91.181.83.228) (Ping timeout)
  1357. # [19:34] * Joins: glenn_ (gadams@174.29.122.75)
  1358. # [19:35] * Quits: glenn (gadams@174.29.103.95) (Ping timeout)
  1359. # [19:38] * Zakim excuses himself; his presence no longer seems to be needed
  1360. # [19:38] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  1361. # [19:41] * plinss is now known as plinss_away
  1362. # [19:44] * Joins: Ms2ger (Ms2ger@91.181.83.228)
  1363. # [19:46] * Quits: karl (karlcow@128.30.54.58) (Quit: :tiuQ tiuq sah woclrak)
  1364. # [19:51] * Joins: TabAtkins_ (tabatkins@74.125.57.241)
  1365. # [20:00] * plinss_away is now known as plinss
  1366. # [20:05] * Quits: TabAtkins_ (tabatkins@74.125.57.241) (Ping timeout)
  1367. # [20:40] * plinss is now known as plinss_away
  1368. # [20:56] * Joins: SteveZ (chatzilla@62.50.196.49)
  1369. # [21:11] * Joins: drublic_ (drublic@95.115.4.190)
  1370. # [21:11] * Quits: drublic (drublic@95.115.4.190) (Connection reset by peer)
  1371. # [22:02] * Joins: miketaylr (miketaylr@201.63.86.140)
  1372. # [22:05] * Quits: Ms2ger (Ms2ger@91.181.83.228) (Quit: nn)
  1373. # [22:16] * Quits: miketaylr (miketaylr@201.63.86.140) (Ping timeout)
  1374. # [22:30] * Joins: ksweeney (ksweeney@63.119.10.10)
  1375. # [22:32] * Parts: ksweeney (ksweeney@63.119.10.10)
  1376. # [22:57] * Quits: glenn_ (gadams@174.29.122.75) (Ping timeout)
  1377. # [23:04] * Joins: glenn (gadams@174.29.112.15)
  1378. # [23:09] * Quits: SteveZ (chatzilla@62.50.196.49) (Ping timeout)
  1379. # [23:09] * Quits: szilles (chatzilla@62.50.199.254) (Ping timeout)
  1380. # [23:10] * Joins: SteveZ (chatzilla@62.50.196.49)
  1381. # [23:10] * Joins: szilles (chatzilla@62.50.196.49)
  1382. # [23:14] * Quits: glenn (gadams@174.29.112.15) (Ping timeout)
  1383. # [23:21] * Joins: glenn (gadams@71.218.123.166)
  1384. # [23:59] * Quits: drublic_ (drublic@95.115.4.190) (Client exited)
  1385. # Session Close: Thu Feb 09 00:00:00 2012

The end :)