/irc-logs / w3c / #css / 2010-11-01 / end

Options:

  1. # Session Start: Mon Nov 01 00:00:00 2010
  2. # Session Ident: #css
  3. # [00:16] * Quits: anne (annevk@80.14.101.159) (Quit: anne)
  4. # [00:22] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  5. # [00:38] * Joins: shepazu (schepers@128.30.52.169)
  6. # [01:45] * Quits: TabAtkinsTPAC (chatzilla@212.180.75.100) (Ping timeout)
  7. # [03:25] * Joins: nimbupani (nimbupani@24.22.131.46)
  8. # [04:57] * Joins: MURATA (makoto@110.4.213.2)
  9. # [04:59] * Joins: arron (Arron@24.17.123.244)
  10. # [05:05] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  11. # [05:42] * Joins: arron (Arron@24.17.123.244)
  12. # [05:44] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  13. # [05:47] * Joins: arron (Arron@24.17.123.244)
  14. # [05:57] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  15. # [06:42] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
  16. # [07:09] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
  17. # [07:31] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
  18. # [07:49] * Joins: TabAtkinsTPAC (chatzilla@212.180.75.100)
  19. # [08:19] * Joins: TabAtkinsTPAC_ (chatzilla@212.180.75.100)
  20. # [08:19] * Quits: TabAtkinsTPAC (chatzilla@212.180.75.100) (Connection reset by peer)
  21. # [08:20] * TabAtkinsTPAC_ is now known as TabAtkinsTPAC
  22. # [08:20] * Quits: timeless_mbp (timeless@81.255.204.171) (Quit: Leaving.)
  23. # [08:35] * Quits: TabAtkinsTPAC (chatzilla@212.180.75.100) (Ping timeout)
  24. # [08:35] * Joins: sylvaing (sylvaing@84.14.50.82)
  25. # [08:44] * Joins: myakura (myakura@84.14.50.82)
  26. # [08:44] * Joins: mgylling (mgylling@84.14.50.82)
  27. # [08:54] * Joins: plinss_ (plinss@84.14.50.82)
  28. # [08:55] * Joins: kojiishi (kojiishi@222.158.227.129)
  29. # [08:56] * myakura yawns
  30. # [08:56] * Joins: johnjan (qw3birc@128.30.52.28)
  31. # [08:57] * Joins: dsinger (dsinger@84.14.50.82)
  32. # [08:57] * Joins: glazou (glazou@84.14.50.82)
  33. # [08:57] * dsinger gooooood morning
  34. # [08:58] * Joins: dbaron (dbaron@63.245.220.11)
  35. # [08:58] <sylvaing> http://wiki.csswg.org/planning/tpac-2010
  36. # [09:00] * Joins: mjs (mjs@84.14.50.82)
  37. # [09:00] * Joins: mmielke (mmielke@84.14.50.82)
  38. # [09:03] * Joins: jun (jun@84.14.50.82)
  39. # [09:04] * Joins: jdaggett (jdaggett@84.14.50.82)
  40. # [09:06] * Joins: tabatkins (tabatkins@84.14.50.82)
  41. # [09:06] <tabatkins> ScribeNick: tabatkins
  42. # [09:07] <tabatkins> glazou: First agenda is the agenda.
  43. # [09:07] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  44. # [09:07] <RRSAgent> logging to http://www.w3.org/2010/11/01-CSS-irc
  45. # [09:07] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  46. # [09:08] * Joins: alexmog (qw3birc@128.30.52.28)
  47. # [09:08] <plinss_> rrsagent, make logs public
  48. # [09:08] <RRSAgent> I have made the request, plinss_
  49. # [09:08] <glazou> http://wiki.csswg.org/planning/tpac-2010
  50. # [09:08] <tabatkins> glazou: What's mos timportant? I think we need clilley for the charter discussion.
  51. # [09:09] <tabatkins> jdaggett: Two things I want to discuss tomorrow are Fonts and Writing Modes.
  52. # [09:09] <tabatkins> sylvaing: We'd like to do Grid first thing tomorrow morning.
  53. # [09:09] <tabatkins> Bert: We have a guest who wants to talk about Writing Modes, and Mike.
  54. # [09:10] <tabatkins> glazou: Microsoft guys, wanna talk about Flexbox before Grid?
  55. # [09:10] <tabatkins> sylvaing: Not that important, just want to talk about both.
  56. # [09:10] <tabatkins> glazou: We can probably start this morning with css3 values.
  57. # [09:11] * Joins: kennyluck (kennyluck@128.30.52.28)
  58. # [09:13] <tabatkins> glazou: FXTF wants to take ownership of 2d transforms. But I want the WG to talk about it too, even if only for a little bit.
  59. # [09:14] <tabatkins> glazou: Marcus Gelling is here, so can we talk about EPUB liaison stuff later this morning?
  60. # [09:14] <tabatkins> Marcus Gelling: Yes.
  61. # [09:14] <tabatkins> glazou: Slow font downloading, should it be lumped with CSS3 Fonts?
  62. # [09:14] * Joins: anne (annevk@84.14.50.82)
  63. # [09:14] <tabatkins> jdaggett: Yes, and hopefully Tues afternoon, because Slye will be here then.
  64. # [09:17] <tabatkins> Attending: Soonbo Han, Tab Atkins, Markus Mielke, Peter Linss, Anne van Kesteren, David Singer, Bert Bos, John Daggett, David Baron, Alex Mogilevsky, Koji Ishii, Sylvain Galineau, John Jansen, Daniel Glazman, Steve Zilles
  65. # [09:18] * Joins: kohei (koheiyamam@124.39.135.110)
  66. # [09:18] <tabatkins> glazou: So I suggest we start with 2d transforms, epub, and css2.1 testing this morning.
  67. # [09:18] * Joins: anthony (qw3birc@128.30.52.28)
  68. # [09:19] <tabatkins> glazou: We now have 4 impls on the table: gecko, webkit, opera, and ms.
  69. # [09:19] * Joins: sbhan (qw3birc@128.30.52.28)
  70. # [09:19] * Quits: kohei (koheiyamam@124.39.135.110) (Quit: Leaving...)
  71. # [09:19] <tabatkins> glazou: We need tests. If we have interop impls - I suppose we have a fairly good level of interop - I think we can move pretty quickly to REC.
  72. # [09:20] <tabatkins> sylvaing: We have some things that need to be resolved, like the DOM interface relying on some obsolete stuff.
  73. # [09:20] * Joins: kohei (koheiyamam@124.39.135.110)
  74. # [09:20] <tabatkins> sylvaing: No one but Webkit implements it yet, I think.
  75. # [09:20] <tabatkins> anne: Maybe we should drop it for now until we figure out what we want to do with the Values APIs.
  76. # [09:20] <tabatkins> glazou: I think marking as at-risk would be better.
  77. # [09:21] <tabatkins> dbaron: The section on Transitions has several bugs in the spec. XXX sent feedback explaining several of them, and you can see these bugs in Webkit.
  78. # [09:21] <tabatkins> s/XXX/bzbarsky/
  79. # [09:22] <sylvaing> CSS3 2D Transforms transition/animation section: http://www.w3.org/TR/css3-2d-transforms/#animation
  80. # [09:22] <tabatkins> dbaron: The other issue is transforms that affect layout.
  81. # [09:22] <tabatkins> dbaron: I could see getting a first version to REC without that, but I'd rather fix it first.
  82. # [09:22] <tabatkins> jdaggett: Isn't that a big issue?
  83. # [09:22] <tabatkins> dbaron: Not necessarily.
  84. # [09:23] <tabatkins> dbaron: Some big things, but some small things.
  85. # [09:23] <tabatkins> sylvaing: That affects things like offsetTop, etc.
  86. # [09:23] <tabatkins> dbaron: Right, but they kind of suck without a layout-effecting transform anyway.
  87. # [09:24] <tabatkins> sylvaing: It would definitely lengthen the time it would take to get to CR.
  88. # [09:25] <tabatkins> dbaron: Yeah, I think it does make sense to move it to CR first without this.
  89. # [09:25] * Joins: anthony_work (qw3birc@128.30.52.28)
  90. # [09:25] <tabatkins> szilles: I drafted a spec for the layout-affecting Transforms 2 or 3 years ago. It's not bug-free, but it exists - we won't be starting from scratch.
  91. # [09:25] <tabatkins> anne: The concern is that nobody's tried to ipmlement it yet.
  92. # [09:26] * Joins: murakami (murakami@118.154.209.3)
  93. # [09:26] <tabatkins> anne: I think that Transforms should redefine the boxes that already exist when transformed; the border box should get bigger, etc.
  94. # [09:27] <tabatkins> anne: So I don't have to constantly reference Transforms when talking about boxes.
  95. # [09:27] <tabatkins> dbaron: You've got 3 or 4 boxes now. 1) Element in its original coord space. 2) Element in the transformed coord space. 3) Rectangle containing the 1st in the 2nd coord space, 4) Rectangle containing the 2nd in the 1st coord space.
  96. # [09:28] <tabatkins> anne: I think browsers act like the transform didn't happen for now.
  97. # [09:28] <tabatkins> anne: Which works for me - if the border box doesn't change, and only alters for painting, that's easy.
  98. # [09:29] <tabatkins> anne: At some point Dean asked me to draft an api that was aware of transforms, but I wasn't sure how to do it.
  99. # [09:29] <tabatkins> sylvaing: We have 4 impls, is what we have enough for authors? Are we missing use-cases?
  100. # [09:29] <tabatkins> dbaron: I think we're definitely missing use-cases, but I think we're still okay to move forward.
  101. # [09:30] <dbaron> s/bzbarsky/bzbarsky forwarded a message from Tim Terriberry/
  102. # [09:30] <tabatkins> glazou: I'd like to talk about canonicalization of the computed value. When you query a transform, I think all browsers respond with a matrix, which is totally unuseful for authors. Is there something we could do to ease this pain?
  103. # [09:31] <tabatkins> anne: I think that, as a string value, having the matrix is fine and the most sane. But I think when people start prototyping the Values API, we'll get a dedicated api for transforms.
  104. # [09:31] * Joins: homata_ (homata@84.14.50.82)
  105. # [09:32] <tabatkins> jdaggett: Once you compose several operations, the matrix loses the state. You can't get the compounded effects anymore. So, glazou, what do you want?
  106. # [09:32] <tabatkins> glazou: For example, if you have a rotation and want to rotate it a bit further, it's a huge pain.
  107. # [09:32] <tabatkins> sylvaing: You can do that now through the matrix api, but it uses CSSValue, which we're not going to implement.
  108. # [09:33] * Joins: timeless_mbp (timeless@84.14.50.82)
  109. # [09:33] <tabatkins> jdaggett: Like, if you do a rotate, transform, rotate, you lose something. What do you want to show to authors?
  110. # [09:33] <tabatkins> glazou: The three operations, hopefully - a stack.
  111. # [09:33] <tabatkins> dbaron: We have to store that information and pass it through anyway to do the transforms.
  112. # [09:34] <tabatkins> s/transforms/transitions/
  113. # [09:34] <tabatkins> glazou: I feel that as a web author, releasing this without having a way to get the scale/rotate/etc of the transform is bad.
  114. # [09:35] <tabatkins> dbaron: Do you really need it at the computed level? Is specified enough? You already have it on the specified level.
  115. # [09:35] <tabatkins> glazou: Yes, but it's a string that you have to parse, which is unacceptable.
  116. # [09:36] <tabatkins> tabatkins: So make Anne work on the Values API faster. ^_^
  117. # [09:36] <tabatkins> szilles: What does SVG do? Also, is the matrix decomposition unique?
  118. # [09:36] <tabatkins> dbaron: There's a reference to an algorithm for a unique decomposition, but it's buggy (I raised this earlier).
  119. # [09:36] * Joins: Ibrahima (qw3birc@128.30.52.28)
  120. # [09:37] <tabatkins> dbaron: I think that authors want back the order they originally specified, though, rather than some canonical transform.
  121. # [09:37] * Quits: Martijnc (Martijnc@91.176.10.131) (Ping timeout)
  122. # [09:38] <anne> tabatkins, the last on that is that people should start experimenting
  123. # [09:38] <tabatkins> sylvaing: Also, SVG can do each transform from a different origin, while CSS does the whole thing from a single origin.
  124. # [09:39] <tabatkins> Anthony (SVG): Doesn't look like SVG has a neat way of getting back the original transforms either.
  125. # [09:39] <tabatkins> glazou: Sounds like something we can discuss in the FXTF meeting.
  126. # [09:41] * Joins: Klaus (Klaus@128.30.52.169)
  127. # [09:41] <tabatkins> RESOLVED: Discuss an API to parse the specified value into an author-convenient form, before pushing the spec forward.
  128. # [09:41] <tabatkins> glazou: Next, tests. What kind of tests do we need for Transforms, who will write them, what schedule?
  129. # [09:42] <tabatkins> glazou: Corollary - do we have enough interop that we can remove prefixes?
  130. # [09:42] <tabatkins> dsinger: If Transitions is going to move slower than Transforms, we should move the section on Transitioning Transforms to the Transitions spec.
  131. # [09:43] <tabatkins> anne: Can we require that this testsuite only has reftests?
  132. # [09:43] <tabatkins> johnjan: No, we can't require it.
  133. # [09:43] <tabatkins> anne: Why not?
  134. # [09:43] * Joins: Martijnc (Martijnc@91.176.19.240)
  135. # [09:44] <tabatkins> tabatkins: Can we resolve that everything that *can* be reftests, *must* be reftests?
  136. # [09:44] <tabatkins> johnjan: Yeah, that's acceptable.
  137. # [09:44] * timeless_mbp is now known as timeless
  138. # [09:45] <tabatkins> dbaron: We have 107 reftests for Transforms. I'd need to ensure they're all test-suite worthy.
  139. # [09:45] <tabatkins> glazou: We'd probably need a lead on the 2d testsuite.
  140. # [09:46] <tabatkins> johnjan: I can do that.
  141. # [09:46] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
  142. # [09:46] <dbaron> (also a bunch of parsing tests)
  143. # [09:47] <tabatkins> glazou: dbaron, can you estimate how many tests we might need for the Transforms spec?
  144. # [09:47] <tabatkins> johnjan: My gut says a few hundred. Right now we have far too few, at least. I'd like to look at SVG and Moz testcases and see how we interop.
  145. # [09:48] <anthony> SVG test suite is here: http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/svg/?sortby=file#dirlist
  146. # [09:48] <fantasai> RESOLVED: Any Transforms tests that can be reftests must be reftests.
  147. # [09:48] * Joins: anne (annevk@84.14.50.82)
  148. # [09:48] <tabatkins> dbaron: Also, a whole lot of our Transforms tests are in our Transitions tests now, because I wrote a whole lot of tests about transitioning transforms.
  149. # [09:49] <anthony> Transforms tests specifically: coords-transformattr-01-f.svg - coords-transformattr-05-f.svg and coords-trans-01-b.svg - coords-trans-14-f.svg
  150. # [09:50] <tabatkins> glazou: 4 impls signals that impls are very interested in this. If we can move fast on this it would be a good signal to the w3c.
  151. # [09:50] <tabatkins> glazou: So, maybe a CR/PR by June would be awesome.
  152. # [09:52] <tabatkins> glazou: Are there immediate actions we can take on the spec, like removing the Transition section, mark layout as at-risk, remove the value api?
  153. # [09:52] * Quits: timeless (timeless@84.14.50.82) (Client exited)
  154. # [09:52] <tabatkins> RESOLVED: Remove the value API from 2d Transforms.
  155. # [09:53] <tabatkins> shepazu: Once you've transformed, getting a point back is no longer in screen space, and there's some tricky transforms you need to do.
  156. # [09:53] <tabatkins> shepazu: So people are going to get a point, expect it to be in one place, and it's not there.
  157. # [09:54] <tabatkins> shepazu: It's a tricky solution but that can be exposed simply for authors.
  158. # [09:54] * Joins: timeless_mbp (timeless@84.14.50.82)
  159. # [09:54] <tabatkins> shepazu: smfr already has a very good idea of what's evolved there, and he'll add it to the 2d transforms spec.
  160. # [09:55] <tabatkins> glazou: More agenda!
  161. # [09:56] <tabatkins> glazou: howcome, we have some things for you.
  162. # [09:56] <tabatkins> howcome: 15 minutes each, they're all easy. ^_^
  163. # [09:56] * Joins: mielke (mmielke@84.14.50.82)
  164. # [09:56] <tabatkins> glazou: today, beginning of afternoon?
  165. # [09:56] <tabatkins> howcome: Yeah.
  166. # [09:57] * Quits: mielke (mmielke@84.14.50.82) (Connection reset by peer)
  167. # [09:57] * Quits: mmielke (mmielke@84.14.50.82) (Connection reset by peer)
  168. # [09:57] * Joins: mmielke (mmielke@84.14.50.82)
  169. # [09:58] <tabatkins> Gylling: I'm the AC rep of the DAISY consortium, but here today for EPUB and the IPDF.
  170. # [09:58] <dsinger> s/Marcus Gelling/Markus Gyllling/
  171. # [09:58] <dbaron> s/Marcus Gelling/Markus Gylling/g
  172. # [09:58] <tabatkins> gylling: This isn't really intended to be a primer for epub, so let's move quickly through that.
  173. # [09:58] <dbaron> s/Markus Gyllling/Markus Gylling/g
  174. # [09:59] <tabatkins> gylling: In the current revision of epub, we have adobe, apple, google, and other organizations working with us.
  175. # [09:59] <tabatkins> gylling: What makes epub stand out in the ebook wars is that epub uses w3c standards as the highest priority.
  176. # [09:59] <tabatkins> gylling: epub is currently undergoing a revision; version 2 has been out for several years, and the new one started this year. We'd like to have the new one out by May 2011.
  177. # [10:00] <tabatkins> jdaggett: What does that mean? Final spec, or impls?
  178. # [10:00] <tabatkins> gylling: Final spec. The ipdf bylaws do not echo the w3c in requiring 2 independent impls.
  179. # [10:00] <tabatkins> gylling: Of course, as we use existing web techs, generally there were already sufficient impls by the time we used something.
  180. # [10:00] <tabatkins> gylling: But the situation is becoming somewhat more tricky now.
  181. # [10:00] <tabatkins> gylling: bert, you sent a few questions earlier?
  182. # [10:01] <tabatkins> Bert: Last time we talked about epub, we tried to discover which documents on the epub wiki were important; which dates, what schedule, etc should we look at?
  183. # [10:01] * Joins: tantek (tantek@70.36.139.128)
  184. # [10:02] <mgylling> http://code.google.com/p/epub-revision/wiki/ImplementationPipeline
  185. # [10:02] <tabatkins> gylling: This is the current schedule.
  186. # [10:02] <tantek> greetings from SF.
  187. # [10:02] <tantek> sorry I couldn't be there in person!
  188. # [10:02] <tabatkins> gylling: So we started out this summer collecting requirements. it was an open-ended process initially.
  189. # [10:03] * Joins: szilles (chatzilla@84.14.50.82)
  190. # [10:03] <tabatkins> gylling: In our SF meeting two weeks ago, we deferred/postponed a large number of our requirements.
  191. # [10:03] <tabatkins> gylling: So we now have a smaller set of requirements that can be reviewed.
  192. # [10:03] <tabatkins> gylling: This is what the epub wg has set out to have done by May next year.
  193. # [10:03] <tabatkins> gylling: There are a few outstanding items, that we'll talk about tomorrow.
  194. # [10:04] <tabatkins> gylling: But one of th emajor things we intend to do in this revision is to increase ou support for i18n.
  195. # [10:04] <tabatkins> gylling: Writing Modes is one of th emost critical features for us right now in epub.
  196. # [10:04] * Joins: jypark (qw3birc@128.30.52.28)
  197. # [10:05] <tabatkins> gylling: The ipdf bylaws enumerates the process to use. Right now the ipdf doens't have an established rule that ther emust be two independent implementations of each feature.
  198. # [10:05] * Quits: Klaus (Klaus@128.30.52.169) (Ping timeout)
  199. # [10:05] <tabatkins> gylling: Inverting the question, though, would an implementation in an ebook device suffice to satisfy the w3c requirements?
  200. # [10:06] <tabatkins> Bert: That's what I was trying to get at. Are your results public?
  201. # [10:06] <tabatkins> gylling: If we can submit test results based on ebook devices, there's not a bunch of problem.
  202. # [10:07] <tabatkins> jdaggett: There's a bit of dependency problem, where there are some drafts that haven't even reached first public draft yet. It seems like that would cause some problems fo ryou guys.
  203. # [10:07] <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant is a testcase showing some of the issues with animation of transforms, and http://lists.w3.org/Archives/Public/www-style/2010Oct/0440.html is the post by Tim Terriberry suggesting an approach to fix that
  204. # [10:07] * sylvaing Billy Idol just entered the room. Or Mike Smith.
  205. # [10:07] <tabatkins> fantasai: I'm trying to stabilize the specs as fast as possible.
  206. # [10:07] <tabatkins> fantasai: If we cannot come to any conclusion on the logical directions issue, we can just not deal with it and do it later, though I'd not like to.
  207. # [10:08] <tabatkins> jdaggett: I just don't believe we should be making any kind of promise until there is some kind of consensus in this group.
  208. # [10:08] <tabatkins> howcome: There seems to be some kind of consensus that epub has accepted the alternate stylesheet approach.
  209. # [10:08] <tabatkins> fantasai: Right. I think epub is clear that Writing Modes is unclear until after TPAC.
  210. # [10:09] <tabatkins> szilles: We shouldn't be having a discussion about what we'll do after a discussion until after the discussion.
  211. # [10:09] * Joins: MoZ (540e3252@128.30.52.43)
  212. # [10:09] <tabatkins> howcome: If I'm right, you're aiming for a per-document writing-mode switch, right?
  213. # [10:10] <tabatkins> fantasai: Right, though you'll have some form of mixed content.
  214. # [10:10] <tabatkins> fantasai: In terms of being able to switch the entire stylesheet, epub has accepted the alternate stylesheet mechanism.
  215. # [10:11] <tabatkins> fantasai: Also, epub has their own way of handling unsupported features, so fallback isn't something we have to address *for epub*. CSS should address that for themselves, but we don't have to worry about that as much.
  216. # [10:11] <tabatkins> howcome: CSS now has a way to do running headers and footers. Will epub adopt that as well?
  217. # [10:11] <dbaron> But how we want implementations that don't support something to handle it is often fundamental to the design rather than something you tack on at the end.
  218. # [10:12] <tabatkins> gylling: Our rendering stuff is generally going to be replaced by references to css 2.1. We haven't discussed running headers and footers yet, but expect that we'll be able to refer to the CSS spec.
  219. # [10:12] <tabatkins> Bert: How does your collab/discussion process work?
  220. # [10:12] <tabatkins> Bert: If we have a question, how do we send it?
  221. # [10:12] <tabatkins> gylling: I think the easiest is to set up a liaison.
  222. # [10:13] <tabatkins> gylling: They would participate in our weekly telcons and our mailing list, which is public.
  223. # [10:13] * Joins: shepazu (schepers@128.30.52.169)
  224. # [10:14] <tabatkins> jdaggett: The way epub is set up, different "working groups" handle different areas. One handles i18n, another handles styling, etc.
  225. # [10:14] <tabatkins> jdaggett: I think there's a minor dependency on CSS3 Speech?
  226. # [10:14] <tabatkins> gylling: Right - i18n and css aren't the only thing. We also need, frex, pagination.
  227. # [10:14] <tabatkins> howcome: What do you mean by pagination?
  228. # [10:15] <tabatkins> gylling: Dynamic reflow and pagination. Also page templates.
  229. # [10:15] <tabatkins> gylling: The feature that overshadows everything else is Writing Modes, though.
  230. # [10:16] <tabatkins> Bert: I'd like to have some names to follow who know what's going on.
  231. # [10:17] <tabatkins> kojiishi: I'm fine with being the liaison for egls (?), but would like someone else that can handle the other groups.
  232. # [10:18] <tabatkins> gylling: I think the main group is 21:00utc, and all the other groups will be re-merging, so everyone should have this as well.
  233. # [10:19] * Joins: r12a-nb (ishida@128.30.52.28)
  234. # [10:19] <tabatkins> MikeSmith: kennyluck has some insights into the vertical text issues as well.
  235. # [10:20] * Quits: Ibrahima (qw3birc@128.30.52.28) (Ping timeout)
  236. # [10:20] <tabatkins> fantasai: I can attend the epub telcon - it's at a sane time in pacific timezone.
  237. # [10:21] * Joins: Aharon (aharon@212.179.82.69)
  238. # [10:21] <tabatkins> gylling: So if I understand correctly, we have a liaison, we'll find out if ebook impls can serve as impls for tests.
  239. # [10:21] <tabatkins> fantasai: ebook readers will certainly serve.
  240. # [10:22] <tabatkins> Bert: Also a question is the test format.
  241. # [10:22] <tabatkins> gylling: I think epub with write access could do the tests in css format and contribute the results directly.
  242. # [10:23] * Joins: MikeSmith (MikeSmith@84.14.50.82)
  243. # [10:23] <tabatkins> Bert: Are there resources set aside for testing purposes?
  244. # [10:23] <tabatkins> gylling: I can't give you firm numbers, but yes, there will be resources for testing.
  245. # [10:23] <tabatkins> Bert: Any idea how many impls you expect to exist?
  246. # [10:24] <tabatkins> gylling: Can't say. But in terms of rendering, there are 4 separate entities, only one of which is based on webkit.
  247. # [10:24] <tabatkins> gylling: CSS3 Speech now.
  248. # [10:24] <tabatkins> gylling: One of the things we're doing in epub is to enhance, for a11y reasons, speech synthesizers.
  249. # [10:25] <tabatkins> gylling: We'd like to bring new life into the css3 speech module.
  250. # [10:25] <tabatkins> gylling: The daisy consortium has a person we'd like to submit as a new editor.
  251. # [10:25] * Joins: ishino (qw3birc@128.30.52.28)
  252. # [10:26] <tabatkins> glazou: No problem.
  253. # [10:26] <tabatkins> jdaggett: As long as they're a W3C member.
  254. # [10:26] <tabatkins> fantasai: I looked over the spec, and I think claudio (?) did a good job of cleaning it up.
  255. # [10:27] * dbaron doesn't see css3-speech in http://www.w3.org/Style/2008/css-charter
  256. # [10:27] <tabatkins> fantasai: I think there's a section we should keep, another we shoudl drop, but otherwise sounds good.
  257. # [10:27] <tabatkins> glazou: Is there already interest in implementing it?
  258. # [10:27] <tabatkins> gylling: Yes, especially from the a11y who wants to interact with epub.
  259. # [10:29] <tabatkins> szilles: There was a point when some phone/voice companies wanted to go with a completely different approach; I don't remember the details, but it seems that we should get whatever we're doing reviewed by the mobile community.
  260. # [10:29] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
  261. # [10:29] <tabatkins> gylling: The people you mentioned are currently meeting as the Speech Incubator group. I'll be meeting with them.
  262. # [10:29] <tabatkins> glazou: Could you report to the WG after you meet with them?
  263. # [10:29] <tabatkins> gylling: I'll try.
  264. # [10:29] * Joins: JonR (Jon@80.195.214.28)
  265. # [10:30] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
  266. # [10:30] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
  267. # [10:30] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
  268. # [10:32] <plinss_> <br type='coffee' />
  269. # [10:32] * Quits: tabatkins (tabatkins@84.14.50.82) (Ping timeout)
  270. # [10:34] * Quits: mmielke (mmielke@84.14.50.82) (Ping timeout)
  271. # [10:35] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
  272. # [10:36] * Joins: glazou (glazou@84.14.50.82)
  273. # [10:36] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
  274. # [10:41] * Quits: jun (jun@84.14.50.82) (Quit: jun)
  275. # [10:49] * Joins: myakura (myakura@84.14.50.82)
  276. # [10:53] <myakura> re css3-speech, WebKit implemented 'speech' property about a month ago. http://webkit.org/b/46827
  277. # [11:01] * Joins: glazou (glazou@84.14.50.82)
  278. # [11:02] * Joins: mgylling (mgylling@84.14.50.82)
  279. # [11:05] * Joins: ilkka (ilkka@188.40.120.199)
  280. # [11:05] * Joins: mjs (mjs@84.14.50.82)
  281. # [11:06] * Joins: tabatkins (tabatkins@84.14.50.82)
  282. # [11:07] <fantasai> Topic: CSS2.1 Testing
  283. # [11:07] <fantasai> round of intros
  284. # [11:07] * Joins: tabatkin1 (tabatkins@84.14.50.82)
  285. # [11:08] <ilkka> my name is Ilkka Oksanen
  286. # [11:08] <dbaron> Present: Ilkka Oksanen, Bert Bos, David Singer, Håkon Lie, Peter Linss, Markus Mielke, Tab Atkins, Soonbo Han, Steve Zilles, Daniel Glazman, John Jansen, Sylvain Galineau, Koji Ishii, Elika Etemad, Alex Mogilevsky, David Baron, John Daggett
  287. # [11:08] * Parts: tabatkin1 (tabatkins@84.14.50.82)
  288. # [11:09] <tabatkins> glazou: Test suite current status?
  289. # [11:09] <tabatkins> fantasai: Published a snapshot last week.
  290. # [11:09] <tabatkins> fantasai: I haven't done any work on it since then.
  291. # [11:09] <tabatkins> dsinger: Because it's perfect?
  292. # [11:09] * Quits: mjs (mjs@84.14.50.82) (Connection reset by peer)
  293. # [11:09] <tabatkins> fantasai: No, I've just been working on other stuff.
  294. # [11:09] * Joins: mjs (mjs@84.14.50.82)
  295. # [11:09] <tabatkins> fantasai: There's still a lot of error reports that ahven't been addressed. I'm guessing a couple weeks.
  296. # [11:10] <tabatkins> glazou: What are the IR results? How many tests that don't pass 2 impls?
  297. # [11:11] <tabatkins> plinss: As of RC3, 135 marked as invalid that havne't been updated yet, 908 tests that are considered required that don't have 2 passes.
  298. # [11:11] <tabatkins> tabatkins: To be clear, a lot of those tests are rc3 and haven't been tested by several browsers yet.
  299. # [11:11] * Joins: mmielke (mmielke@84.14.50.82)
  300. # [11:12] <tabatkins> jdaggett: Question on what versions are allowed?
  301. # [11:13] <tabatkins> plinss: Public availability, and results must be a month old.
  302. # [11:14] * Quits: ishino (qw3birc@128.30.52.28) (Ping timeout)
  303. # [11:15] <tabatkins> jdaggett: I have a problem with using source-code versions, because it's hard to ensure that I run the exact same version that the test results were generated for.
  304. # [11:16] <tabatkins> fantasai: I think we should require a public *binary*, not just source.
  305. # [11:16] <tabatkins> tabatkins: So, we only release binaries for our public channel, every 6 weeks or so.
  306. # [11:16] * Joins: kennyluck (kennyluck@128.30.52.28)
  307. # [11:16] <fantasai> s/fantasai/jdaggett/
  308. # [11:16] <tabatkins> johnjan: So, IE9 developer previews count?
  309. # [11:17] * Joins: jun (jun@84.14.50.82)
  310. # [11:17] <tabatkins> jdaggett: Sure, as long as we can get historical versions that the suite was run for.
  311. # [11:17] <tabatkins> johnjan: I'll check to see if, say, when we release preview 7, if preview 6 is still available. if not, I'll stick with beta.
  312. # [11:18] <tabatkins> dsinger: Are there tests that are failing because the spec is wrong?
  313. # [11:18] * Quits: mjs (mjs@84.14.50.82) (Connection reset by peer)
  314. # [11:18] * Joins: mjs (mjs@84.14.50.82)
  315. # [11:19] <tabatkins> dbaron: There were some, yes. I marked some of them, but others I didn't feel strongly enough about to file a bug about.
  316. # [11:19] <tabatkins> dbaron: There were some invalids where the test was requiring something the spec doesn't actually require. There were some that were actually testing the wrong thing. And then there was a third category that were testing something where I believe the spec itself was wrong.
  317. # [11:20] <tabatkins> glazou: I'd like to see all info about that in front of the group as soon as possible.
  318. # [11:20] <tabatkins> dsinger: I'd just like a good wiki page somewhere that lists all the tests in each of those categories.
  319. # [11:20] <tabatkins> dsinger: And then slowly see that page empty out until we're done.
  320. # [11:21] <tabatkins> dsinger: I've gone through every mozilla failure and figured out if it was a bug in the test or in our impl, based on what the spec currently said.
  321. # [11:21] * Joins: dethbakin (dethbakin@84.14.50.82)
  322. # [11:21] <tabatkins> s/dsinger/dbaron/
  323. # [11:22] * Zakim excuses himself; his presence no longer seems to be needed
  324. # [11:22] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  325. # [11:22] <tabatkins> dbaron: There were some places where the test was testing things the spec didn't require and I could have marked invalid, but I went ahead and marked it a mozilla fail because our actual behavior was so wrong. Like Lists numbering, frex.
  326. # [11:23] <tabatkins> fantasai: CSS3 Lists defines list numbering, but CSS2.1 doesn't.
  327. # [11:23] <fantasai> http://wiki.csswg.org/test/css2.1/issues
  328. # [11:23] * Quits: Aharon (aharon@212.179.82.69) (Ping timeout)
  329. # [11:23] <tabatkins> glazou: My problem is that I don't have any stable visibility on the status of the testsuite.
  330. # [11:23] <tabatkins> jdaggett: So what are you proposing, daniel? A specific date?
  331. # [11:24] <tabatkins> glazou: I propose we buckle down on CSS2.1 issues again. I think that rather than cancelling the first conf call after tpac, we have it and talk about test suite.
  332. # [11:25] <tabatkins> johnjan: Is Nov 15th still the date for not changing the testsuite, or at least just triaging at that point?
  333. # [11:26] <tabatkins> fantasai: That's a little early. I'll need two weeks after this for my changes.
  334. # [11:26] <tabatkins> johnjan: Yeah, and we'll also need to do reviews of the changes.
  335. # [11:26] <tabatkins> johnjan: So is 2 weeks enough time?
  336. # [11:26] <tabatkins> dbaron: What I want is, when we think we have all the changes done, I want to go through and rerun/reverify. So that's a dependency there.
  337. # [11:27] * Joins: Peter (peter@85.223.116.170)
  338. # [11:27] <tabatkins> fantasai: I think I'm about halfway through the reported issues in my tests, and have responded to each test issue email as I completed the fix.
  339. # [11:28] <tabatkins> fantasai: But I don't know that arronei did it to all of his, and that would make it much more difficult to judge what all has been done.
  340. # [11:29] <tabatkins> johnjan: So we can review the changes as they come in now, and on the 22nd review what's gone on and see if we're ready or we need another 2 weeks, etc.
  341. # [11:29] <dbaron> I just went through the list of things that I thought were "too silly to file a bug" on, and one more I noticed is the test that tests that the root element's background is propagated to the canvas even when the root element is display:none.
  342. # [11:30] * Joins: yuma_1985 (yuma_1985@84.14.50.82)
  343. # [11:30] <tabatkins> glazou: So we'll have IRs based on the locked version by the end of year?
  344. # [11:30] <tabatkins> johnjan: Early december, I think.
  345. # [11:30] * Joins: Aharon (aharon@84.14.50.82)
  346. # [11:33] <tabatkins> plinss: [explains how results are handled in each version of the test suite harness, and how results are grandfathered over when tests don't change]
  347. # [11:34] * Joins: joonho (joonholee@84.14.50.82)
  348. # [11:34] <tabatkins> jdaggett: Also, could you record the useragent language? Some of the font tests are locale-specific.
  349. # [11:34] * dbaron wants to bring up an issue with Ahem-related tests
  350. # [11:34] <tabatkins> plinss: Yes, I have the useragent data, so I'll pull that data out.
  351. # [11:37] <tabatkins> RESOLVED: Target Nov 22nd for test suite RC4 freeze.
  352. # [11:37] <tabatkins> dbaron: Did you publish change lists from rc1-2, and rc2-3?
  353. # [11:37] <tabatkins> fantasai: I think I did rc2-3.
  354. # [11:37] <tabatkins> plinss: I have changed test data, so I can generate a list like that.
  355. # [11:38] <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0369.html
  356. # [11:38] <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0005.html
  357. # [11:38] <tabatkins> johnjan: I'd like to bring up a question about a consistent place to store the impl reports - the .data files.
  358. # [11:38] <tabatkins> johnjan: I can't find a consistent place, and I don't think attachments on the list are a good place to store them.
  359. # [11:39] <fantasai> ACTION fantasai: update links from W3C to implementation reports and test suite releases
  360. # [11:39] * trackbot noticed an ACTION. Trying to create it.
  361. # [11:39] * RRSAgent records action 1
  362. # [11:39] <trackbot> Created ACTION-272 - Update links from W3C to implementation reports and test suite releases [on Elika Etemad - due 2010-11-08].
  363. # [11:39] <tabatkins> plinss: I've put them in the rc1 and rc2 folders as appropriate.
  364. # [11:39] <tabatkins> dbaron: We have a larg enumber of IR bugs because of one issue with Ahem fonts where the tests are questionably valid.
  365. # [11:40] <tabatkins> dbaron: The Ahem font has a lot of glyphs that are boxes - they are exactly 1em tall and wide.
  366. # [11:40] <tabatkins> dbaron: The baseline of the font is 4/5ths from the top to the bottom of the font.
  367. # [11:40] <tabatkins> dbaron: So all the ascent metrics are 80% of the em square, the descents are 20%.
  368. # [11:41] <tabatkins> dbaron: So the issue is that if the ahem font is used at a size that is not a multiple of 5px, then the ascent/descent/x-height aren't a round number of pixels.
  369. # [11:41] <tabatkins> dbaron: On Windows, our font metrics backend makes it okay.
  370. # [11:41] <tabatkins> dbaron: We don't get good enough information anyway, so we just throw one out and subtract from the height.
  371. # [11:42] <tabatkins> dbaron: But on Linux we get good info, so we use both the ascent and descent data, and both are rounded up.
  372. # [11:42] <tabatkins> dbaron: So a pretty large amount of our test failures are because the Ahem font isn't a multiple of 5px.
  373. # [11:42] <tabatkins> dbaron: I marked them as Moz bugs, but I could equally mark them as invalid, which could flip 50-80 tests.
  374. # [11:43] <tabatkins> jdaggett: I think that in general we shouldn't be relying on rounding behavior.
  375. # [11:44] <tabatkins> chrisl: And we don't have a canonical place to look for font data, since different font apis on different platforms return different data.
  376. # [11:44] <tabatkins> alexmog: The spec doesn't say that fonts have to be round numbers of pixels.
  377. # [11:44] <tabatkins> jdaggett: Yes, but the spec also doesn't specify how to round, so we can't rely on rounding.
  378. # [11:46] <tabatkins> chrisl: Can we just ignore the fact that windows does weird things? We have two impls that use correct platform behavior.
  379. # [11:46] <jdaggett> waterfall test for non-integer font sizes:
  380. # [11:46] <jdaggett> http://people.mozilla.org/~jdaggett/tests/decimalfontwaterfalls.html
  381. # [11:47] <jdaggett> alexmog: ^
  382. # [11:47] <tabatkins> dbaron: The rounding behavior is part of freetype, actually. I've tried to change our rounding behavior, but it actually broke several things, like text-decorations no longer lining up exactly.
  383. # [11:47] <MikeSmith> RRSAgent, make minutes
  384. # [11:47] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-CSS-minutes.html MikeSmith
  385. # [11:47] <tabatkins> s/windows/windows GDI/
  386. # [11:48] <tabatkins> glazou: We need a way to report invalid/problematic tests. Everyone should report invalid tests asap, and try to meet the guidelines we discussed today.
  387. # [11:48] <tabatkins> dbaron: For the record, i went through all the mozilla failures. There were a small number of tests I gave up on. I havne't gotten to those yet.
  388. # [11:49] <tabatkins> dbaron: Some were font ones, which I handed to jdaggett.
  389. # [11:49] <tabatkins> jdaggett: I fixed the tests.
  390. # [11:49] <dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0178.html
  391. # [11:49] <dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0175.html
  392. # [11:49] <tabatkins> jdaggett: But the metric ones we still need to look at.
  393. # [11:51] <dbaron> And the other Moz failures I didn't analyze were margin-collapse-157, margin-collapse-clear-005 and margin-collapse-clear-011
  394. # [11:51] <tabatkins> dbaron: And also some margin-collapse issues, which I skipped because it takes me too long to try and figure out what's intended there.
  395. # [11:51] <tabatkins> chrisl: Perhaps that's a spec problem, if an implementor finds it too difficult to figure out from the spec what should happen.
  396. # [11:51] <tabatkins> fantasai: We just rewrote that section of the spec.
  397. # [11:52] <tabatkins> Topic: i18n
  398. # [11:52] <tabatkins> richard ishida and aharon lenin introduce themselves
  399. # [11:52] <tabatkins> also david clarke (sp?)
  400. # [11:52] <johnjan> so 11/22 for Elika's changes to the Test Suite, 12/8 Conf Call for getting complete on reviewing those test changes and completing the IR submissions.
  401. # [11:53] <tabatkins> also kennyluck
  402. # [11:53] <tabatkins> fantasai: The point of i18n is to make everyone in the world happy with our technologies.
  403. # [11:53] <tabatkins> fantasai: 2 major topics: bidi, and vertical text.
  404. # [11:54] <tabatkins> fantasai: We're doing vertical text tomorrow.
  405. # [11:54] <tabatkins> fantasai: aharon wanted to discuss bidi-related proposals for css3.
  406. # [11:54] * timeless_mbp is now known as timeless
  407. # [11:54] <tabatkins> Aharon: First thing i wanted to discuss was a couple of new proposals that I emailed to the list last night.
  408. # [11:55] <tabatkins> Aharon: Second is to get a feeling on the acceptance level on the other bidi stuff that has been dsicussed ove rth elast year.
  409. # [11:55] <Bert> s/lenin/lanin/
  410. # [11:55] <tabatkins> Aharon: New stuff. (1) A small addition to Images.
  411. # [11:55] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Nov/0000.html
  412. # [11:55] <tabatkins> Aharon: I'd like an ability to flip an image based on directionality.
  413. # [11:56] <myakura> http://www.w3.org/International/docs/html-bidi-requirements/#image-flip
  414. # [11:56] <tabatkins> Aharon: One option is an 'rtlflip' keyword, so the image would be flipped horizontally when the direction is rtl.
  415. # [11:57] <tabatkins> jdaggett: This isn't just bidi - vertical text may want to do rotations too. So, this is a writing-mode thing.
  416. # [11:57] <tabatkins> Aharon: The other way was to declare the directionality of the image, and then auto-flip as appropriate.
  417. # [11:58] <tabatkins> Aharon: So if the image is ltr and the text is ltr, leave it alone. If the text is rtl, then flip the image.
  418. # [11:59] <tabatkins> szilles: One slight modification; I think this is a much better way to go as it describes the image. I think you need to separate the idea of the image directionality from whether or not to flip it.
  419. # [11:59] * Joins: Kai (chatzilla@84.14.50.82)
  420. # [12:00] <tabatkins> szilles: Because an image might be neutral in horizontal, but not in vertical.
  421. # [12:00] <tabatkins> szilles: Would this apply to any replaced element?
  422. # [12:00] <tabatkins> fantasai: If this should apply to all replaced elements, this should be handed to the HTMLWG as this would be a content property.
  423. # [12:02] <tabatkins> johnjan: One problem is backwards compat.
  424. # [12:03] <tabatkins> fantasai: Not a problem in CSS, as you can count on the property being ignored in legacy and just add a fallback.
  425. # [12:03] <tabatkins> szilles: So I'm hearing that we aren't intended to cover <img>?
  426. # [12:04] <tabatkins> fantasai: For content images, in most cases I don't believe you'd generally want to flip those images.
  427. # [12:04] <tabatkins> fantasai: The types of images you get in CSS are very often something you want to flip.
  428. # [12:04] <tabatkins> fantasai: But images that belong in the content tend to be pictures, charts, etc. that you are much less likely to want to flip.
  429. # [12:04] <tabatkins> fantasai: Now, if the use-case pops up and proves important, then at that point we'd push this back to the HTMLWG and ask them to fix the problem.
  430. # [12:05] <tabatkins> szilles: Good, I just wanted to be clear on the scope.
  431. # [12:05] * Quits: timeless (timeless@84.14.50.82) (Client exited)
  432. # [12:07] * Quits: Aharon (aharon@84.14.50.82) (Ping timeout)
  433. # [12:07] <fantasai> dbaron: should look into how this interacts with Exif orientation
  434. # [12:08] <fantasai> http://dev.w3.org/csswg/css3-images/#image-orientation
  435. # [12:08] <tabatkins> dbaron: We had a spec somewhere relating to EXIF transformations and similar. We might want to think about how this transformation compounds with the exif orientation.
  436. # [12:08] <fantasai> dbaron: Didn't we have a boolean to honor the exif orientation?
  437. # [12:08] <tabatkins> tabatkins: If honored, it should happen at a level below the rtl flipping.
  438. # [12:09] <tabatkins> dbaron: While it's arguably correct to honor the EXIF orientation, there's probably a lot of web content that depends on EXIT not being honored.
  439. # [12:09] * Joins: timeless_mbp (timeless@84.14.50.82)
  440. # [12:09] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
  441. # [12:09] * fantasai notes that the spec there needs updating to add back that auto value
  442. # [12:09] * Joins: Aharon (aharon@84.14.50.82)
  443. # [12:10] <tabatkins> dsinger: Any image editor that doesn't set EXIF correctly is buggy. It's not our responsibility to fix their bugs.
  444. # [12:11] * gsnedders notes that he can be poked on IRC if it would help for the next hour and a half or so, but can't guarantee that he knows everything about CSS :)
  445. # [12:11] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  446. # [12:11] <tabatkins> tabatkins: We can't break webpages either.
  447. # [12:12] <tabatkins> howcome: We should mandate a default behavior of not honoring, and have a property allowing honoring it.
  448. # [12:12] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Nov/0004.html
  449. # [12:12] <tabatkins> dbaron: Also, theoretically attr() and Generated Content could let us handle <img>s in HTML.
  450. # [12:12] <tabatkins> Aharon: Next topic. You have list-style-position, which lets you put the marker inside or outside.
  451. # [12:13] <tabatkins> Aharon: I'm only talking about the outside case.
  452. # [12:13] <tabatkins> Aharon: Currently the bullet goes on the "start" side, based on the item's directionality.
  453. # [12:13] * Joins: mjs (mjs@84.14.50.82)
  454. # [12:13] <tabatkins> Aharon: Which sounds reasonable, until one realizes that one often has a list where the items are mixed directionality.
  455. # [12:13] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
  456. # [12:13] <tabatkins> Aharon: For example, a bibliography where some are english and some are hebrew.
  457. # [12:14] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
  458. # [12:14] <tabatkins> Aharon: The obvious answer is to put @dir on the <li>s directly, but that swaps bullets around inconsistently. so you have to instead wrap a span and tag *that* with directionality, which is suboptimal.
  459. # [12:14] <fantasai> I would suggest the syntax list-style-direction: left | right | start | match-parent, to be parallel with text-align
  460. # [12:14] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
  461. # [12:15] <tabatkins> Aharon: Further, the list itself creates a gutter for the bullet based on the list's direction.
  462. # [12:15] <tabatkins> Aharon: If the bullets are mixed, then the bullets for items in the other direction are often invisible because they're off-page.
  463. # [12:15] <tabatkins> Aharon: So my proposal is list-style-direction, which indicates the direction of the marker.
  464. # [12:15] <tabatkins> Aharon: Four values: ltr, rtl, match-list, match-item.
  465. # [12:16] <tabatkins> dbaron: I'm inclined to think we should instead find the right answer, and not expose this directly at all.
  466. # [12:17] <tabatkins> Aharon: The use-case for having it match item is that in arabic, they sometimes like having markers on different sides.
  467. # [12:18] <tabatkins> dbaron: You said that the gutter for the list is a function of the list's direction. I think that varies between browsers. In gecko it should match the child's direction.
  468. # [12:19] <tabatkins> dbaron: Wait, maybe I've got that wrong. The gutter is always generated by the list.
  469. # [12:19] <tabatkins> dbaron: Also, in CSS Lists, there's no concept of a "list", just list items. So you'd need match-parent, not match-list.
  470. # [12:21] <tabatkins> dbaron: What I think is that, semantically, in the case that you have a list with differeing directionality items, the list-items themselves are all the same directionality, but the *content* has different directions.
  471. # [12:21] <tabatkins> szilles: I'm curious why dbaron doesn't want a property there.
  472. # [12:23] <tabatkins> dbaron: I don't think a full property is warranted to just change the behavior of a single value of anothe rproperty.
  473. # [12:23] * Quits: Aharon (aharon@84.14.50.82) (Ping timeout)
  474. # [12:24] <tabatkins> Aharon: Maybe we can just do this as another value on list-style-position? Currently 'outside' refers to the direction of the list-item. Maybe a 'list' value that would be like outside but use the parent's directionality?
  475. # [12:24] <tabatkins> aharon: When you text-align anything but start, in IE the outside marker follows the text, so they don't line up.
  476. # [12:25] <tabatkins> aharon: Webkit doesn't make the marker move, so they still all line up.
  477. # [12:26] <tabatkins> aharon: In my opinion, the webkit behavior is more useful. You can use list-style-position:inside to make the marker follow the text.
  478. # [12:27] <tabatkins> dbaron: We received a ton of feedback from authors that they don't like the bullet being separated from the text.
  479. # [12:27] <tabatkins> dbaron: This is also tied somewhat to issues of floats and such. When the linebox is shortened we need to specify where the bullet goes.
  480. # [12:27] <tabatkins> dbaron: Right now we tie the bullet to the first line box.
  481. # [12:28] <tabatkins> tabatkins: It seems conceptually consistent to make 'outside' follow the list-item's text, but make the new value 'match-parent' or whatever line them up separate from the text.
  482. # [12:30] * fantasai tabatkins did you catch Aharon's last set of comments?
  483. # [12:31] <fantasai> dbaron: We still need to displace bullets from floats by match-parent
  484. # [12:32] <tabatkins> aharon:
  485. # [12:32] * sylvaing discussion of minutes-writing-mode ensues...
  486. # [12:33] <tabatkins> aharon: Finally, I want to check on the status of the bidi things that I haven't been direclty working on, which fantasai has been keeping on top of.
  487. # [12:33] <tabatkins> glazou: Tab, could you keep up a wiki or something for an issues list for Lists?
  488. # [12:33] <tabatkins> tabatkins: Yeah.
  489. # [12:33] <fantasai> tabatkins, you missed something Aharon said, can you put it in the minutes?
  490. # [12:34] <dbaron> fantasai, that was <tabatkins> aharon: Finally, I want to check on the status of the bidi things that I haven't been direclty working on, which fantasai has been keeping on top of.
  491. # [12:34] <fantasai> No, you missed it. He was describing the behavior of match-parent on both list markers and text alignment and how they interact
  492. # [12:34] <fantasai> You did not catch any of that.
  493. # [12:34] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
  494. # [12:34] * Joins: mjs (mjs@84.14.50.82)
  495. # [12:34] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
  496. # [12:34] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
  497. # [12:35] * Quits: jdaggett (jdaggett@84.14.50.82) (Quit: jdaggett)
  498. # [12:35] <myakura> <br type=lunch>
  499. # [12:35] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
  500. # [12:35] <fantasai> The entire discussion of text-align and its interaction with the list marker was not minuted.
  501. # [12:35] * Quits: plinss_ (plinss@84.14.50.82) (Quit: plinss_)
  502. # [12:36] <fantasai> s/marker/marker position/
  503. # [12:36] <dbaron> Basically the idea is that with list-style-position: outside, bullets should stick to the line box (wrap for both text-align and floats), but with list-style-position: outside-parent the direction of the bullet position matches the parent, and the wrapping only accounts for floats and does not account for text-align
  504. # [12:36] * Quits: tabatkins (tabatkins@84.14.50.82) (Ping timeout)
  505. # [12:37] * Quits: jypark (qw3birc@128.30.52.28) (Ping timeout)
  506. # [12:37] * Quits: mmielke (mmielke@84.14.50.82) (Ping timeout)
  507. # [12:37] * Parts: mjs (mjs@84.14.50.82)
  508. # [12:37] * Quits: sbhan (qw3birc@128.30.52.28) (Ping timeout)
  509. # [12:38] * Quits: joonho (joonholee@84.14.50.82) (Ping timeout)
  510. # [12:38] <fantasai> Yes, an Aharon was discussing how that behavior handles certain use cases that are needed
  511. # [12:38] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
  512. # [12:38] * Quits: jun (jun@84.14.50.82) (Quit: jun)
  513. # [12:38] <fantasai> Because, e.g. some lists are rendered with bullets all on one side
  514. # [12:38] * Quits: szilles (chatzilla@84.14.50.82) (Ping timeout)
  515. # [12:38] * Quits: anthony (qw3birc@128.30.52.28) (Ping timeout)
  516. # [12:38] <fantasai> but an item of opposite directionality might be aligned to the opposite side
  517. # [12:39] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
  518. # [12:39] <fantasai> while leaving the bullet aligned with the others in the list
  519. # [12:39] * Quits: homata_ (homata@84.14.50.82) (Ping timeout)
  520. # [12:39] <dbaron> (and with list-style-position:outside the side for the bullet matches the item, as now)
  521. # [12:39] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  522. # [12:44] * Quits: sylvaing (sylvaing@84.14.50.82) (Ping timeout)
  523. # [12:49] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
  524. # [12:52] * Parts: JonR (Jon@80.195.214.28)
  525. # [13:03] * Quits: johnjan (qw3birc@128.30.52.28) (Ping timeout)
  526. # [13:07] * Quits: tantek (tantek@70.36.139.128) (Quit: tantek)
  527. # [13:12] * Quits: kohei (koheiyamam@124.39.135.110) (Quit: Leaving...)
  528. # [13:28] * Joins: jdaggett (jdaggett@84.14.50.82)
  529. # [13:36] * Joins: plinss_ (plinss@84.14.50.82)
  530. # [13:39] * Joins: joonho (joonholee@84.14.50.82)
  531. # [13:39] * Quits: yuma_1985 (yuma_1985@84.14.50.82) (Connection reset by peer)
  532. # [13:40] * Joins: glazou (glazou@84.14.50.82)
  533. # [13:40] * Joins: myakura (myakura@84.14.50.82)
  534. # [13:42] * Joins: sylvaing (sylvaing@84.14.50.82)
  535. # [13:42] * Joins: joonho_2010 (joonholee@84.14.50.82)
  536. # [13:42] * Quits: joonho (joonholee@84.14.50.82) (Ping timeout)
  537. # [13:42] * Joins: mmielke (mmielke@84.14.50.82)
  538. # [13:43] * Joins: szilles (chatzilla@84.14.50.82)
  539. # [13:43] * Joins: dethbakin (dethbakin@84.14.50.82)
  540. # [13:44] * Joins: anne (annevk@84.14.50.82)
  541. # [13:45] * Joins: tabatkin1 (tabatkins@84.14.50.82)
  542. # [13:45] * Joins: sbhan (qw3birc@128.30.52.28)
  543. # [13:45] * Quits: joonho_2010 (joonholee@84.14.50.82) (Ping timeout)
  544. # [13:45] * Joins: parkjy (qw3birc@128.30.52.28)
  545. # [13:46] * Joins: joonho_2010 (joonholee@124.39.135.110)
  546. # [13:47] * Quits: r12a-nb (ishida@128.30.52.28) (Ping timeout)
  547. # [13:47] <fantasai> ScribeNick: fantasai
  548. # [13:47] * Joins: Ms2ger (Ms2ger@91.181.144.192)
  549. # [13:47] <fantasai> Topic: Accessibility
  550. # [13:48] <fantasai> Topic: Multi-Col
  551. # [13:48] <fantasai> howcome: I would like to confirm agreement on a few things
  552. # [13:49] <fantasai> howcome: Implementations seem to be coming along nicely
  553. # [13:49] <fantasai> howcome: Hopefully all of the functionality in the spec
  554. # [13:49] <fantasai> howcome: We need some clarifications in the spec
  555. # [13:49] <fantasai> howcome: It's all about spanning elements
  556. # [13:49] * Joins: dbaron (dbaron@63.245.220.11)
  557. # [13:49] <fantasai> howcome: Remember we have a multicol element here, and we lay out incolums
  558. # [13:49] <fantasai> howcome draws on the board
  559. # [13:49] <fantasai> howcome: The issue is overflow
  560. # [13:50] <fantasai> howcome: There are two reasons for overflow: you could have a constrained height
  561. # [13:50] <fantasai> howcome: or you could have forced column breaks, more breaks than you have columns
  562. # [13:50] <fantasai> howcome: The issue is what to do if you have an element with column-span: all in one of the overflow columns
  563. # [13:51] <fantasai> howcome: Alex proposed to do nothing, i.e. pretend column-span was not set
  564. # [13:51] * Joins: Aharon (aharon@84.14.50.82)
  565. # [13:51] * Parts: Aharon (aharon@84.14.50.82)
  566. # [13:52] <fantasai> howcome: If it's in the overflow columns due to forced breaks, though, I think it makes sense to have it break the column row and render as column-span: all, with content following it filling in columns in a row below it
  567. # [13:52] <fantasai> dbaron: What if you have both a constrained height and forced breaks?
  568. # [13:52] <dbaron> that wasn't me
  569. # [13:53] <fantasai> Alex: If it's due to forced breaks, you can try to put it in the main section. And if it doesn't fit and cause overflow, then you put it in an overflow column and ignore the spanning behavior
  570. # [13:53] <fantasai> s/dbaron/?/
  571. # [13:53] * Joins: mgylling (mgylling@212.180.75.100)
  572. # [13:53] <fantasai> Alex: One special case: when you try to place a colspan and it itself doesn't fit, and creates overflow. That creates a circular dependency
  573. # [13:54] <fantasai> Alex: I think we resolved that if it doesn't fit as a span, you ignore the span
  574. # [13:54] * Joins: kennyluck (kennyluck@128.30.52.28)
  575. # [13:54] <fantasai> howcome: So the distinction is, if it fits inside the multicol element as a span, then it does so, else the spanning behavior is ignored
  576. # [13:55] <fantasai> dbaron: You could also ignore in all cases whether there's a constrained height
  577. # [13:55] <fantasai> stevez: I think it should be if it fits or not
  578. # [13:55] <dbaron> s/whether/when/
  579. # [13:56] <fantasai> howcome: I think we should honor it in as many cases as possible, so I think we should hinge this on whether there's room or not
  580. # [13:56] <fantasai> stevez: This might interact with the EPUB case, where they paginate in addition to doing multicol
  581. # [13:57] * Joins: yuma_1985 (yuma_1985@84.14.50.82)
  582. # [13:58] * Joins: homata (homata@84.14.50.82)
  583. # [13:58] * Joins: Kai (chatzilla@84.14.50.82)
  584. # [14:01] <fantasai> Alex: If the forced-break case is height-constrained, where does the overflow columns go?
  585. # [14:01] * Joins: shepazu (schepers@128.30.52.169)
  586. # [14:01] <fantasai> Alex: Do the columns overflowing from the second row have full height, or shortened height, i.e. height after the rowspan?
  587. # [14:01] * Quits: dethbakin (dethbakin@84.14.50.82) (Connection reset by peer)
  588. # [14:01] <fantasai> dbaron: So you're saying whether colspan works at all...
  589. # [14:02] <fantasai> howcome: is dependent on whether there is room inside the multicol element
  590. # [14:02] * fantasai notes that she had an issue and needs to minute it
  591. # [14:03] <fantasai> Alex: This could create a very ugly case if you have only one line of space left at the bottom of the multicol. you would create one-line-high overflow columns off to the right
  592. # [14:03] * Joins: johnjan (qw3birc@128.30.52.28)
  593. # [14:03] * Joins: dethbakin (dethbakin@84.14.50.82)
  594. # [14:04] <fantasai> Alex: As the available space after the colspan approaches zero, the number of columns for content after it approaches infinity
  595. # [14:06] <fantasai> fantasai: From an implementation perspective, I would prefer this method.
  596. # [14:06] <fantasai> fantasai: The main reason we simplified column-span to 1 or all instead of arbitrary numbers was to avoid a column row with columns of multiple heights
  597. # [14:06] <fantasai> fantasai: if overflow columns were full-height columns, then we lose that simplification
  598. # [14:07] <szilles> What Stevez was saying was that Epub wants to have pagination, expecially in the multicolumn case, because they want to avoid overflow behavior when there are mulitiple columns
  599. # [14:07] <fantasai> fantasai: (Also, if forced-column-breaks can create overflow columns, then your full-height columns would overpaint any such overflowing columns before the column span)
  600. # [14:08] <fantasai> [note to minutes: insert pictures]
  601. # [14:09] <fantasai> dbaron draws some content on the board
  602. # [14:09] <fantasai> I have a some text, then a forced break, then more content.
  603. # [14:09] <fantasai> Then a spanning element.
  604. # [14:10] <fantasai> tab, fantasai: Then you balance the content, which may introduce breaks in the column before the forced break or after it or both
  605. # [14:11] <fantasai> RESOLVED: If a columnspanning element doesn't fit within the multicol element, then it doesn't span anymore
  606. # [14:12] <fantasai> s/element/element without overflowing/
  607. # [14:12] <fantasai> New questions:
  608. # [14:12] <fantasai> 1. do columnspanning elements create a new block formatting context
  609. # [14:13] <fantasai> 2. does columnspanning turn inline elements into blocks?
  610. # [14:13] <fantasai> 3. If the answer to either of the above is yes, does that behavior apply when the columnspanning is ignored due to overflowing (as resolved above)?
  611. # [14:15] <fantasai> 2... or does it not apply to inline elements
  612. # [14:16] <fantasai> fantasai: I think column-span should only apply to block-level elements
  613. # [14:17] <fantasai> Bert reads the applies-to line from the spec
  614. # [14:17] <fantasai> RESOLVED: column-span applies to "in-flow block-level elements"
  615. # [14:18] <fantasai> dbaron: Note in the prose that it has no effect on elements outside a multicol element
  616. # [14:18] <dbaron> Well, really I said that maybe the in-flow aspect is the same as the doesn't-work-outside-multicol aspect, and then we got to that conclusion.
  617. # [14:18] * Joins: freedom (freedom@84.14.50.82)
  618. # [14:19] <dbaron> fantasai: If a column-spanning element is a BFC root, then margins don't collapse through its boundaries.
  619. # [14:19] <tabatkin1> fantasai: I don't think that margin behavior should change based on whether a colspan is honored or not.
  620. # [14:19] <sylvaing> CSS3 Multicolumn http://www.w3.org/TR/css3-multicol/
  621. # [14:19] <tabatkin1> fantasai: So if it's a spanning element, it should automatically become a BFC and no longer collapse margins through its boundary.
  622. # [14:20] <fantasai> whether or not it's triggered the overflow nonspanning case
  623. # [14:21] * Joins: arron (Arron@24.17.123.244)
  624. # [14:21] <fantasai> fantasai: I think we might need to distinguish whether an element is spanning one column or not spanning
  625. # [14:22] <fantasai> dbaron: I really don't want whether something is a block formatting context root depend on layout
  626. # [14:22] * Joins: dsinger (dsinger@84.14.50.82)
  627. # [14:22] <fantasai> dbaron: I really want to know what floats are relative to not depend on layout
  628. # [14:23] <fantasai> tabatkin1: So they should become BFCs regardless of whether they actually span something or not
  629. # [14:24] <fantasai> dbaron: We shouldn't have tricky behavior for an error case
  630. # [14:24] <fantasai> Steve: So column-span: all; would mean span the current column in the overflow case
  631. # [14:24] <fantasai> Steve: i.e. the all in that case means the one column
  632. # [14:25] * Joins: ChrisL (ChrisL@128.30.52.169)
  633. # [14:25] <fantasai> RESOLVED: column-spanning elements are BFC roots always
  634. # [14:27] <fantasai> RESOLVED: Initial value of column-span is 'none'
  635. # [14:28] <fantasai> Bert: Last issue is, do margins between spanning elements collapse?
  636. # [14:29] * Quits: freedom (freedom@84.14.50.82) (Quit: leaving)
  637. # [14:29] * Joins: freedom (freedom@84.14.50.82)
  638. # [14:29] <fantasai> Bert: e.g. if I have H2 followed by H3, can their margins collapse
  639. # [14:29] <fantasai> fantasai: What about between the spanning element and the content of the columns above and below it?
  640. # [14:30] <fantasai> Roughly, answers seem to be Yes, and No, but discussing...
  641. # [14:31] <fantasai> Back to fantasai's issue
  642. # [14:34] * Quits: mgylling (mgylling@212.180.75.100) (Quit: mgylling)
  643. # [14:35] <fantasai> fantasai: If you get more columns than you have space for due to forced column breaks, then I think instead of overflowing to the right, I think the columns that don't fit should create a new column row rather than overflowing off to the side.
  644. # [14:36] <fantasai> fantasai: This way we avoid an overflow case.
  645. # [14:37] <fantasai> Alex: I'm concerned people would use this for some weird design cases that don't work well
  646. # [14:38] <sylvaing> (that was szilles)
  647. # [14:39] <fantasai> steve zilles echoes the concern
  648. # [14:39] <Bert> (If the columns "wrap," i.e., the n+1st column starts underneath the 1st, then this becomes a way to make a grid in some cases. Effect is almost the same between 'display: inline-block' and 'break-after: always'...)
  649. # [14:39] <fantasai> dbaron: I'm concerned that we're getting too far from what we're implementing
  650. # [14:40] <fantasai> howcome: We have implementations of multicol, we have to resolve these issues
  651. # [14:40] * Quits: glazou (glazou@84.14.50.82) (Client exited)
  652. # [14:40] * Quits: freedom (freedom@84.14.50.82) (Ping timeout)
  653. # [14:40] <fantasai> dbaron: We're not getting much author feedback on columns
  654. # [14:40] * szilles aaron, the reason for column-span="none" is to be able to say that an element without an explicit column-span value does not create a Block Formattring Context
  655. # [14:40] <fantasai> tabatkin1: They're not useful in continuous media
  656. # [14:41] <johnjan> s /aaron /arron
  657. # [14:41] * Joins: glazou (glazou@84.14.50.82)
  658. # [14:43] <fantasai> more discussion of this case
  659. # [14:44] <fantasai> steve zilles thinks this solution causes bad layout
  660. # [14:44] <fantasai> fantasai thinks avoiding overflow is important
  661. # [14:44] * Joins: mgylling (mgylling@84.14.50.82)
  662. # [14:45] <fantasai> steve: People will insert forced breaks randomly in order to get the layout they want
  663. # [14:46] * Joins: alexmog (qw3birc@128.30.52.28)
  664. # [14:46] <tabatkin1> fantasai: [draws a multicol element overflowing, showing how block-column overflow would result in a bad overflow situation in the constrained height case]
  665. # [14:47] <tabatkin1> fantasai: [draws another one where the multicol has an auto height and stretches to fill the content]
  666. # [14:48] <tabatkin1> tabatkin1: Assuming overflow:visible, yeah, it looks ugly. But you only get the good overflow if you have explicit column breaks based on where you think is "good".
  667. # [14:48] <tabatkin1> fantasai: Right, so far. Ideally we'll have in the future a "column-length" that can cause new column rows.
  668. # [14:48] <arron> referring to the first drawing by fantasai, are the columns overflowing to the right or below?
  669. # [14:49] * tabatkin1 arron, they're overflowing down, overlapping content in later elements.
  670. # [14:49] * dbaron but the drawing is to say that's why they don't overflow down
  671. # [14:50] <tabatkin1> fantasai: So if we think that column length is needed to get a sane rendering, maybe we should go ahead and just add column-length now.
  672. # [14:50] <tabatkin1> szilles: I could live with multiple breaks overflowing to the right today.
  673. # [14:52] <fantasai> fantasai: I'm not happy with creating overflow cases when they are not necessary
  674. # [14:52] <fantasai> fantasai: And if we do this today, then you would have to use column-length in order to get explicit-break columns to wrap
  675. # [14:52] <fantasai> tabatkin1: column-length is not the right trigger for wrapping overflowing explicit break columns
  676. # [14:52] <fantasai> tabatkin1: if they're explicit breaks, they're explicit breaks
  677. # [14:53] <fantasai> tabatkin1: If you set column-length: 40em; and your explicit breaks are at 20em, what's your column row height?
  678. # [14:54] <fantasai> steve: Ok, I see what you're saying
  679. # [14:55] <fantasai> Steve: Ok, I'm willing to withdraw my objection provided you add a note about this column-length property
  680. # [14:55] <fantasai> steve: My concern is that people will start putting in explicit breaks just to get the behavior that column-length would have given
  681. # [14:56] <fantasai> Steve: But if you at least put in the spec that this is not intended for this purpose, and how we want to proceed
  682. # [14:56] <fantasai> Peter: Authors don't read the spec. They'll do whatever it takes to make content work the way they want it right now.
  683. # [14:57] <fantasai> Peter: Let's just put this property in right now.
  684. # [14:57] <fantasai> dbaron: I'm not sure this is useful
  685. # [14:57] <fantasai> tabatkin1: This would make multicol usable for me
  686. # [14:58] <fantasai> Peter: Fundamentally, multicol doesn't make much sense on continuous media
  687. # [14:58] <fantasai> Peter: But let's not force people into making unusable layouts.
  688. # [14:59] * Joins: freedom (freedom@84.14.50.82)
  689. # [14:59] <fantasai> dbaron: I'm not sure we're addressing use cases with multicol
  690. # [15:00] * Quits: Kai (chatzilla@84.14.50.82) (Ping timeout)
  691. # [15:01] <fantasai> dbaron: And I don't think we would implement all this.
  692. # [15:01] <fantasai> fantasai: column-length is a piece of cake
  693. # [15:01] <fantasai> dbaron: But we don't implement column-spanning. And we can't balance columns with forced column breaks in our current design.
  694. # [15:01] <fantasai> ?: We have a lot of demand for this, actually.
  695. # [15:02] <fantasai> ?: We haven't switched from table layouts to CSS due to lack of multicol
  696. # [15:03] <fantasai> howcome: So how would you decide the gap between the column rows?
  697. # [15:03] <fantasai> fantasai: use column-gap
  698. # [15:04] <fantasai> fantasai: can give it two values, just like border-spacing, if needed
  699. # [15:04] <fantasai> Alex: I want separate properties
  700. # [15:04] <fantasai> fantasai: Do you need them to cascade independently?
  701. # [15:04] <fantasai> Alex: I just like having separate properties
  702. # [15:05] <fantasai> fantasai: If we need separate properties, we can split them out later and make column-gap a shorthand.
  703. # [15:05] <fantasai> Steve: In XSLFO, we replicated the multicol box
  704. # [15:06] * Joins: Kai (chatzilla@84.14.50.82)
  705. # [15:06] <fantasai> s/?/Kai/
  706. # [15:07] <fantasai> various concerns raised to porting this idea to CSS
  707. # [15:07] <Bert> (Chained regions, e.g., César's extensions to template layout, would solve most use cases as well. That, too, is an example of pagination inside a continuous display...)
  708. # [15:08] <fantasai> Steve: I'm going back to my position of putting a note that this doesn't solve the following problems.
  709. # [15:09] <fantasai> howcome: We go back to the issue of where the overflowing forced-break column goes: off to the right, or wrap under?
  710. # [15:09] <fantasai> howcome: I'm in favor of wrapping under, quite stronger.
  711. # [15:10] <fantasai> Alex: You need gap and rules, though.
  712. # [15:12] <fantasai> fantasai thinks we should just use the column-gap and deal with customized gaps and rules later
  713. # [15:13] * Joins: Kai_ (chatzilla@84.14.50.82)
  714. # [15:14] * Quits: Kai (chatzilla@84.14.50.82) (Ping timeout)
  715. # [15:14] * Kai_ is now known as Kai
  716. # [15:15] <fantasai> steve: But I don't think column-gap is good enough.
  717. # [15:15] <Kai> q+ to say that currently control over layout is key
  718. # [15:15] <fantasai> fantasai: I'm not saying it's good enough, I'm saying it's adequate as a default even in the future when we have all these controls
  719. # [15:15] * glazou let's use the axiomatic proof....
  720. # [15:16] <fantasai> fantasai: The only other reasonable default is a zero gap. I don't see how that's better
  721. # [15:16] <fantasai> ...
  722. # [15:16] <fantasai> tabatkin1 doesn't want to half-ass this
  723. # [15:16] <fantasai> ...
  724. # [15:16] * sylvaing we should add half-ass to RFC2119
  725. # [15:16] <fantasai> Kai: Web page layout is very precise right now.
  726. # [15:16] <fantasai> Kai: Automatically wrapping columns loses precision
  727. # [15:18] <fantasai> Kai: It's easier to control if it always overflows to the right
  728. # [15:19] <Kai> it would be good to have this as default and have the ability to have it wrap
  729. # [15:20] <fantasai> howcome takes a straw poll on behavior
  730. # [15:20] <fantasai> A - overflow to the right
  731. # [15:20] <fantasai> B - wrap under
  732. # [15:20] <fantasai> Bert: A
  733. # [15:20] <fantasai> Kai: A
  734. # [15:20] <fantasai> Steve: A
  735. # [15:20] <fantasai> Peter: B
  736. # [15:20] <fantasai> Markus: A
  737. # [15:20] <fantasai> Tab: A
  738. # [15:20] <fantasai> beth: A
  739. # [15:20] <fantasai> ?: A
  740. # [15:20] <fantasai> ??: B
  741. # [15:20] <fantasai> Chris: A
  742. # [15:21] <fantasai> Daniel: A
  743. # [15:21] <fantasai> John: A
  744. # [15:21] <fantasai> Sylvain: A
  745. # [15:21] <fantasai> Koji: A
  746. # [15:21] <arron> Arron: A assuming right is actually end
  747. # [15:21] <fantasai> fantasai: B
  748. # [15:21] <fantasai> arron, :)
  749. # [15:21] <fantasai> Alex: A
  750. # [15:21] <fantasai> dbaron: A
  751. # [15:21] <fantasai> jdaggett: A
  752. # [15:21] <fantasai> no comment from the peanut gallery
  753. # [15:22] <dbaron> howcome: B
  754. # [15:23] <glazou> s/peanut gallery/other observers
  755. # [15:23] * Quits: glazou (glazou@84.14.50.82) (Client exited)
  756. # [15:23] * timeless_mbp is now known as timeless
  757. # [15:24] * Joins: glazou (glazou@84.14.50.82)
  758. # [15:24] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
  759. # [15:24] * dsinger dave: D
  760. # [15:24] <fantasai> Peter: I think it's unfortunate that we're choosing a behavior for multicol that doesn't work well for print
  761. # [15:24] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
  762. # [15:24] <fantasai> RESOLVED: overflow to the right
  763. # [15:25] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
  764. # [15:26] * Peter is now known as beverloo
  765. # [15:26] * Quits: tabatkin1 (tabatkins@84.14.50.82) (Ping timeout)
  766. # [15:28] * Quits: sbhan (qw3birc@128.30.52.28) (Ping timeout)
  767. # [15:30] * Quits: joonho_2010 (joonholee@124.39.135.110) (Ping timeout)
  768. # [15:30] * Quits: timeless (timeless@84.14.50.82) (Client exited)
  769. # [15:32] * Joins: timeless_mbp (timeless@84.14.50.82)
  770. # [15:32] * Joins: nimbupani (nimbupani@24.22.131.46)
  771. # [15:32] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
  772. # [15:34] * Quits: freedom (freedom@84.14.50.82) (Connection reset by peer)
  773. # [15:37] * Joins: tantek (tantek@70.36.139.128)
  774. # [15:38] * Joins: tabatkins (tabatkins@84.14.50.82)
  775. # [15:39] * Joins: yuma_1986 (yuma_1985@84.14.50.82)
  776. # [15:39] * Quits: yuma_1985 (yuma_1985@84.14.50.82) (Connection reset by peer)
  777. # [15:41] <kennyluck> RRSAgent, make minutes
  778. # [15:41] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-CSS-minutes.html kennyluck
  779. # [15:42] * Quits: homata (homata@84.14.50.82) (Ping timeout)
  780. # [15:42] * Joins: sbhan (qw3birc@128.30.52.28)
  781. # [15:44] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
  782. # [15:45] * Joins: johnjan (qw3birc@128.30.52.28)
  783. # [15:47] * Joins: mgylling (mgylling@84.14.50.82)
  784. # [15:49] * Joins: homata (homata@84.14.50.82)
  785. # [15:54] * Quits: yuma_1986 (yuma_1985@84.14.50.82) (Ping timeout)
  786. # [15:54] * Quits: homata (homata@84.14.50.82) (Ping timeout)
  787. # [16:00] * Joins: glazou (glazou@84.14.50.82)
  788. # [16:00] * Joins: yuma_1986 (yuma_1985@84.14.50.82)
  789. # [16:04] * Joins: Kai (chatzilla@84.14.50.82)
  790. # [16:09] * Joins: homata (homata@84.14.50.82)
  791. # [16:10] * timeless_mbp is now known as timeless
  792. # [16:11] * Joins: dethbakin (dethbakin@84.14.50.82)
  793. # [16:11] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
  794. # [16:12] * Joins: joonho (joonholee@124.39.135.110)
  795. # [16:12] * Quits: timeless (timeless@84.14.50.82) (Client exited)
  796. # [16:12] <tabatkins> http://www.xanthir.com/blog/b48Z0
  797. # [16:12] <fantasai> tabatkins: I put up a list of all the new changes that Alex and I have agreed on for the flexbox draft
  798. # [16:13] <fantasai> fantasai suggests putting that on the mailing list
  799. # [16:13] <fantasai> tabatkins: Most are pretty small; syntax-level changes
  800. # [16:14] <fantasai> tabatkins: Major one is that we're changing the prefix from box- to flex-
  801. # [16:14] <fantasai> tabatkins: Because box is overloaded in CSS
  802. # [16:14] <fantasai> tabatkins: The next is determining the direction
  803. # [16:14] * Joins: dethbakin (dethbakin@84.14.50.82)
  804. # [16:14] <fantasai> tabatkins: We used to have two properties for that
  805. # [16:14] <fantasai> tabatkins: Don't believe they need to cascade independently, so merged them into one that has all combinations
  806. # [16:15] <fantasai> dbaron: That probably makes sense
  807. # [16:16] <fantasai> tabatkins: At the last F2F sorta decided that things should flex differently when they're growing from when they're shrinking
  808. # [16:16] * Joins: mollydotcom (mollyh@68.225.52.230)
  809. # [16:16] <fantasai> tabatkins: e.g. having the biggest flex, which normally becomes the biggest, become the smallest when shrinking
  810. # [16:16] <fantasai> tabatkins: Split into flex-grow and flex-shrink
  811. # [16:17] <fantasai> tabatkins: Also margins participate in flexing
  812. # [16:17] <fantasai> tabatkins: 'auto' flexes as 1
  813. # [16:17] <fantasai> tabatkins: Very common use case was splitting things to align half items on left, half on right
  814. # [16:17] <fantasai> tabatkins: previously had to add a dummy element
  815. # [16:17] <fantasai> tabatkins: now can do that with margins
  816. # [16:18] <fantasai> tabatkins: Keeping box-ordinal-group, renamed to something shorter
  817. # [16:18] <fantasai> tabatkins: Multiple lines, not super-sure about
  818. # [16:18] * Joins: timeless_mbp (timeless@84.14.50.82)
  819. # [16:18] <fantasai> tabatkins: Seems like a large enough topic that it should be addressed more thoroughly
  820. # [16:18] * Joins: freedom (freedom@84.14.50.82)
  821. # [16:18] * timeless_mbp is now known as timeless
  822. # [16:18] <fantasai> Alex: There are no current implementations right now of multiple lines
  823. # [16:18] <fantasai> tabatkins: so thinking we might push that for the next level
  824. # [16:19] <fantasai> Alex: What was the motivation for multiple lines?
  825. # [16:19] <fantasai> dbaron: You'd have to ask hyatt. Not sure he'd know either
  826. # [16:19] <fantasai> Alex: We had some use cases that seemed interesting, but not sure any of them are really important.
  827. # [16:19] <fantasai> Alex: One example of multi-line box is a dialog box with a lot of tabs
  828. # [16:19] <fantasai> Alex: But that's not a good design to begin
  829. # [16:20] <fantasai> with
  830. # [16:20] * Quits: freedom (freedom@84.14.50.82) (Connection reset by peer)
  831. # [16:21] <fantasai> Alex: The biggest problem with multicol is how to handle the last line
  832. # [16:21] <fantasai> Alex: Sometimes there's only one item on the last line
  833. # [16:21] <fantasai> Alex: I'm not sure I've seen any good design for this
  834. # [16:21] * Joins: smfr (smfr@68.183.26.22)
  835. # [16:21] <fantasai> Alex: So multiline is only useful in combination with max width or something like that
  836. # [16:22] <fantasai> fantasai had a use case of a catalog, with tiles representing each item;
  837. # [16:22] <fantasai> fantasai: But pushing multiline flexbox to a next level makes sense to me
  838. # [16:22] <fantasai> tabatkins: The major change is alignment in the transverse direction
  839. # [16:22] <fantasai> tabatkins: Previously handled with box-align, which would align the box to the top, bottom, or centered
  840. # [16:23] <fantasai> tabatkins: or could stretch the box
  841. # [16:23] <fantasai> tabatkins: I expressed some unhappiness about that design
  842. # [16:23] <fantasai> tabatkins: I spent some time looking at it and realized you can do every case except baseline with margins
  843. # [16:23] * Bert (Talking about tab cards: I'd still like some way to turn a UL, or a sequence of SECTIONs, into a stack of cards with tabs... But that's unrelated to flexbox.)
  844. # [16:23] <fantasai> tabatkins: Current proposal is to have one keyword that makes the box shrink
  845. # [16:24] <fantasai> tabatkins: Can align that box with margins
  846. # [16:24] <fantasai> tabatkins: ...
  847. # [16:24] <fantasai> dbaron: The thing that seems weird to me is if the child is itself a flexbox with the alignment in the other direction
  848. # [16:25] <fantasai> dbaron: It's unclear whether to throw out box-align or throw out box-pack
  849. # [16:25] <fantasai> dbaron: normally the child is in the orthogonal direction
  850. # [16:25] <fantasai> dbaron: The control was for the alignment in the axis direction
  851. # [16:25] * fantasai is not understanding
  852. # [16:25] <fantasai> dbaron: With your new proposal, if the child is a flexbox with an orthogonal direction
  853. # [16:25] <fantasai> dbaron: which do you use?
  854. # [16:26] <fantasai> dbaron: because you have two different things telling you how to align stuff
  855. # [16:26] <fantasai> tabatkins: depends what the child wants to be
  856. # [16:26] * Joins: freedom (freedom@84.14.50.82)
  857. # [16:26] <fantasai> fantasai: I'm getting confused here
  858. # [16:27] <fantasai> Alex: I think it's a good point. What we're trying to do here is require that the child layout has certain capabilities
  859. # [16:27] <fantasai> Alex: So far there is only one precedent of requirement for nested layout, ability to declare its own baseline
  860. # [16:27] <fantasai> Alex: We're adding requirement of declaring vertical alignment
  861. # [16:27] <fantasai> Tab draws a big box with two small boxes inside
  862. # [16:27] <fantasai> one on the left one on the right
  863. # [16:28] <fantasai> right child has three boxes stacked vertically and is a flexbox
  864. # [16:28] <fantasai> left child has squiggles aligned to the top
  865. # [16:28] <fantasai> align: before assigned to big box
  866. # [16:28] <fantasai> pack: end assigned to right child
  867. # [16:29] <fantasai> Tab: Hm, I see what your'e talking about. Yes, this explicitly resolved somehow
  868. # [16:29] <fantasai> dbaron: I think you'd want the thing on the child to beat the one on the parent
  869. # [16:29] * Joins: ibrahima_ (qw3birc@128.30.52.28)
  870. # [16:29] <fantasai> fantasai: Maybe make it not apply to flexboxes
  871. # [16:30] <fantasai> Alex: What if the left one is a table?
  872. # [16:30] <fantasai> dbaron: I think you want these differentiations to apply to non-flexbox children
  873. # [16:31] <fantasai> Alex: Could define this alignment to only apply to block containers
  874. # [16:31] <fantasai> dbaron: baseline has its own problems with vertical-axis flexboxes. That's it's own problem
  875. # [16:32] <fantasai> Alex: We're making a complicated problem just to solve baseline alignment. Not sure it's worth it.
  876. # [16:32] <fantasai> Tab: baseline alignment is very common for e.g. tab strips
  877. # [16:33] <fantasai> Tab: Say I have <ul> with <li>, render as a horizontal flexbox tab strip
  878. # [16:33] <fantasai> Tab: Would want different alignments, bottom aligned, baseline aligned, centered...
  879. # [16:34] <fantasai> Alex: .. nested elements?
  880. # [16:34] <fantasai> Tab: How would you do that with nested elements?
  881. # [16:35] <fantasai> fantasai: You might want to align to the top baseline or to the bottom baseline
  882. # [16:35] <fantasai> Alex: Let's step back and talk about logistics of the spec
  883. # [16:36] <fantasai> Alex: Let's suppose hypothetically that next implementation comes out with this new syntax
  884. # [16:36] <fantasai> Alex: Are the existing implementations going to add another new prefixed implementation for this new spec and then on the next round it will become standard which will be in three years from now? Is that the route that we are looking at?
  885. # [16:36] <fantasai> Alex: The alternative would be to make small changes to the spec which makes Mozilla and WebKit implementations nearly compatible with the spec
  886. # [16:37] <fantasai> Alex: Which means next release of webkit/mozilla/ie would bring us close to CR
  887. # [16:38] <fantasai> Tab: There are some changes that are important and we definitely want, e.g. flex-grow flex-shrink split
  888. # [16:38] * Joins: rigo (rigo@128.30.52.169)
  889. # [16:38] <fantasai> Alex: Question is do we consider existing implementations important in validating the spec, in which case we are trying to make less changes as long as they are equivalent
  890. # [16:38] <fantasai> Alex: Or are we taking the position that we are changing everything freely
  891. # [16:38] <fantasai> Alex asks dbaron
  892. # [16:39] <fantasai> dbaron: I think in the end we're going to have to rewrite a lot of it either way. Hard to say when that's going to happen.
  893. # [16:39] <fantasai> dbaron: But I think we should try and get this right.
  894. # [16:39] <fantasai> Alex: I'm not as concerned with complexity of implementations. I just want this to stabilize faster. Want to know if that matters.
  895. # [16:40] <fantasai> dbaron: What are these changes relative to?
  896. # [16:41] <fantasai> Tab: Last official WD
  897. # [16:42] <fantasai> Tab: Dropped idea of flex units, since couldn't figure out baseline alignment with that.
  898. # [16:44] <fantasai> discussion of stability, etc.
  899. # [16:44] <fantasai> Markus suggests this is parallel to multicol, fantasai says it's not nearly as advanced--hasn't gone through design review, which we are doing now
  900. # [16:46] <fantasai> more discussion of stability and implementation release schedules and interop on old syntax etc
  901. # [16:46] <fantasai> Alex is concerned about interop on old standard
  902. # [16:46] <fantasai> instead of on new standard
  903. # [16:47] <fantasai> Tab: We can try to make changes to box-align more minor.
  904. # [16:48] <fantasai> Tab: I tried to leave it unchanged and mix in vertical-align to align contents
  905. # [16:48] <fantasai> Tab; But wasn't getting sane answers when I tried to map out how that works
  906. # [16:49] * Quits: freedom (freedom@84.14.50.82) (Ping timeout)
  907. # [16:50] <fantasai> ...
  908. # [16:50] <fantasai> dbaron: I like the idea of using vertical-align. Want to know what the issues were.
  909. # [16:51] <fantasai> Alex: If we resolve on everything except baseline, and can get those edits into the spec, that would be a great outcome of this meeting.
  910. # [16:52] <fantasai> RESOLVED: Change prefix from box- to flex-
  911. # [16:52] * Joins: freedom (freedom@84.14.50.82)
  912. # [16:52] <fantasai> Next issue: combining box-orient and box-direction into flex-direction
  913. # [16:52] <fantasai> Alex: I'm not too thrilled with changing that. think old is more intuitive
  914. # [16:52] <fantasai> dbaron thinks the opposite: prefers Tab's proposal
  915. # [16:53] <fantasai> RESOLVED: Combine box-orient and box-direction into flex-direction
  916. # [16:53] <fantasai> RESOLVED: Split box-flex into flex-grow and flex-shrink
  917. # [16:54] <fantasai> dbaron: I think what the spec said and what implementations did is different
  918. # [16:54] <fantasai> fantasai: So maybe look into what current implementations do to determine default behavior of flex-shrink
  919. # [16:55] <fantasai> Should auto margins flex as one?
  920. # [16:55] <fantasai> fantasai: I'm strongly in favor
  921. # [16:55] <fantasai> RESOLVED: 'auto' margins flex as 1
  922. # [16:56] * Quits: szilles (chatzilla@84.14.50.82) (Ping timeout)
  923. # [16:56] <fantasai> Tab: Drop box-flex-group? Not sure on this one
  924. # [16:56] <fantasai> dbaron: I think splitting out flex-shrink would solve many of the use cases here
  925. # [16:57] <fantasai> dbaron: Note we don't implement flex-group
  926. # [16:57] <fantasai> Alex: We haven't heard any significant use cases, and it's expensive to implement
  927. # [16:58] <fantasai> RESOLVED: Drop box-flex-group
  928. # [16:58] <fantasai> Drop multiple-line support?
  929. # [16:58] <fantasai> Alex: Mark at-risk?
  930. # [16:59] <fantasai> dbaron: We should drop before CR if we're not sure that the spec is ready
  931. # [16:59] <fantasai> dbaron: At-risk is something that is ready to be implemented, but we're not sure that it will be implemented
  932. # [16:59] <dbaron> I'm ok with either way.
  933. # [16:59] <fantasai> Tab: The existing behavior is well-specified, just too simplistic to be useful
  934. # [17:00] <fantasai> RESOLVED: Mark multiline at-risk.
  935. # [17:01] <fantasai> RESOLVED: Rename box-ordinal-group to either flex-order or flex-index (mark as issue)
  936. # [17:01] <fantasai> Tab: Multiple lines .. current syntax is to take values of single or multiple
  937. # [17:01] <fantasai> Tab: Suggest to change to box-wrap: wrap | nowrap
  938. # [17:02] <fantasai> fantasai: Makes sense to me.
  939. # [17:03] <fantasai> Alignment in transverse direction
  940. # [17:03] <fantasai> Alex: Would it help to solve this problem if you could independently specify background on the flexbox item from the actual child?
  941. # [17:04] * Joins: howcome (howcome@84.14.50.82)
  942. # [17:04] <fantasai> Tab: It's weird, but would solve my use case
  943. # [17:04] <fantasai> fantasai cringes
  944. # [17:04] <fantasai> dbaron: Would prefer to solve it some other way than a pseudo-element
  945. # [17:05] <fantasai> RESOLVED: Mark entire transverse alignment as an issue until further notice.
  946. # [17:05] <fantasai> Topic: GCPM
  947. # [17:05] <howcome> http://dev.w3.org/csswg/css3-gcpm/#page-selection-nth
  948. # [17:05] <fantasai> howcome: Two issues I have
  949. # [17:06] <fantasai> howcome: One thing we cut out earlier this year was named page lists
  950. # [17:06] <fantasai> howcome: But the requirement is still there
  951. # [17:06] <fantasai> howcome: There's a use case for being able to style pages differently.
  952. # [17:07] <fantasai> howcome: Named page lists approach was heavyweight; not suggesting to re-add that
  953. # [17:07] <fantasai> howcome: Suggesting :nth page selector
  954. # [17:08] <fantasai> howcome: Here's an example *pulls up nearest book*
  955. # [17:08] <arron> I would prefer this to be :nth-page not just :nth
  956. # [17:10] * Joins: hsivonen (hsivonen@130.233.41.50)
  957. # [17:10] <fantasai> howcome: You don't want headings on the spread of a chapter heading
  958. # [17:10] * Joins: bradk (bradk@99.7.175.117)
  959. # [17:10] <fantasai> fantasai: How about :first, :middle, :last?
  960. # [17:11] <fantasai> howcome: Need to access 2nd page
  961. # [17:11] <fantasai> fantasai: what for?
  962. # [17:11] <fantasai> howcome: both pages on the spread of the chapter heading need to be selected to e.g. drop headers
  963. # [17:13] <fantasai> discussion of how to indicate the start and end of a named series
  964. # [17:13] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
  965. # [17:13] <dbaron> I think if you want @page chapter:nth(2), you need a new value for the 'page' property that makes a new chapter "restart" the sequence of chapter pages.
  966. # [17:14] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
  967. # [17:14] <fantasai> Tab: You could have a :spread() that takes a page name, and is true if either side of the spread has a page with that name
  968. # [17:15] <fantasai> fantasai: But all the pages in that book are "chapter" pages. You have to somehow distinguish the start and end of a particular chapter page series
  969. # [17:16] <fantasai> howcome explains some use case involving widows and changing page sizes
  970. # [17:17] <fantasai> glazou: complex selectors are very hard to present in a UI
  971. # [17:17] <fantasai> glazou: I'm not saying the feature is not needed, just presenting a warning
  972. # [17:20] <fantasai> dbaron: You want the nth page of that name.
  973. # [17:20] <fantasai> dbaron: But that's actually different from the nth page
  974. # [17:21] <fantasai> dbaron: They should be separate selectors
  975. # [17:21] <dbaron> Some of these examples are :nth-of-name(), some are :nth-page()
  976. # [17:21] <dbaron> or maybe :nth-of-name() should be :nth-of-sequence()
  977. # [17:22] <dbaron> ?: maybe we don't need nth... just first-in-sequence?
  978. # [17:22] <fantasai> fantasai: Seems to me you just need to address the first page, first spread, last page, and last spread of a named series
  979. # [17:22] * Quits: freedom (freedom@84.14.50.82) (Connection reset by peer)
  980. # [17:23] * Quits: smfr (smfr@68.183.26.22) (Quit: smfr)
  981. # [17:23] * Joins: freedom (freedom@84.14.50.82)
  982. # [17:23] <fantasai> howcome: The case I need to address an arbitrary page is to address widows and orphans
  983. # [17:24] <fantasai> howcome: The publisher doesn't want to have a single line alone on a page
  984. # [17:24] <fantasai> howcome: so he tweaks the size of the page before it to accommodate an extra line
  985. # [17:25] <fantasai> Bert: TeX alters the line-height for this case
  986. # [17:25] <fantasai> howcome: It's a spread. You want to keep the baselines even
  987. # [17:25] <fantasai> Peter: you have this exact same problem in columns
  988. # [17:25] <fantasai> Tab: Maybe we need more powerful orphan-widow properties
  989. # [17:26] * Joins: mjs (mjs@84.14.50.82)
  990. # [17:26] <fantasai> Peter: I don't like that we're targetting the page by number
  991. # [17:27] <fantasai> Peter: You don't want to target the page with a problem.
  992. # [17:28] <fantasai> Peter: If I edit the document: change the content, or the styling, the problem is no longer on the page I targetted.
  993. # [17:28] <fantasai> glazou: It's a hack
  994. # [17:30] <fantasai> Discussion returns to the 'page' property
  995. # [17:30] * Joins: anne (annevk@84.14.50.82)
  996. # [17:31] <tabatkins> glazou: What happens if the element that triggers a page group has a page break property. Then it's impossible to know which page is the second page he wants.
  997. # [17:31] <tabatkins> howcome: If it's inserted before, you don't count it.
  998. # [17:31] <tabatkins> howcome: The idea is that every chapter starts on the left of a spread.
  999. # [17:32] <tabatkins> howcome: And you want to remove the headings on the second page of the chapter.
  1000. # [17:33] <tabatkins> glazou: No, you want to remove it on the other page of the spread that the chapter start is in.
  1001. # [17:33] <tabatkins> tabatkins: If the chapters start on the right, then you want to alter the last pag eof th eprevious chapter, instead.
  1002. # [17:34] * Bert thinks the sequence of named pages wasn't so bad...
  1003. # [17:34] <tabatkins> fantasai: [explains why chapter:first doesn't work, with analogy to p:first-child]
  1004. # [17:35] <tabatkins> fantasai: [explains :first-page(pagename), and :first-spread(pagename)]
  1005. # [17:36] <tabatkins> howcome: That doesn't solve the widows problem.
  1006. # [17:38] * Quits: homata (homata@84.14.50.82) (Ping timeout)
  1007. # [17:38] <tabatkins> plinss: It doesn't fully solve the existing problem, either. If the chapter starts on a right page, and the left page has content, you don't necessarily want to style the left page.
  1008. # [17:39] <fantasai> :first(pagename) selects the page on which an element with page: pagename; starts
  1009. # [17:39] <tabatkins> howcome: Yeah, you don't want to select backwards. Just select the second page, if the chapter starts on a left page.
  1010. # [17:39] <fantasai> :first-spread(pagename) selects that page and potentially the next page if they are part of the same spread
  1011. # [17:39] <fantasai> similarly for :last-page(pagename) and :last-spread(pagename)
  1012. # [17:40] <tabatkins> tabatkins: Okay, if that's the case then I don't have a problem with selecting the second page explicitly.
  1013. # [17:41] <tabatkins> glazou: I think that this offers too much power - it will be abused.
  1014. # [17:42] <fantasai> and you can combine with :left or :right for styling as needed
  1015. # [17:42] <Kai> Wondering about workflows. As discussed now a piece of text to be printed will have to be styled after all textual changes have been made. Any changes to the text before that might change the layout and leave the author to re-style the whole text.
  1016. # [17:43] <fantasai> Peter: Whether you have left and right pages or just right pages is a print-time decision
  1017. # [17:43] <fantasai> fantasai: not in CSS. All pages are classified as left or right
  1018. # [17:43] <fantasai> howcome: Right, suppose you're printing to PDF
  1019. # [17:43] <fantasai> Peter: If I print this document in non-duplex mode, I don't want left and right pages
  1020. # [17:44] <fantasai> Alex: could you have a media query for whether you have facing pages?
  1021. # [17:46] <fantasai> unminuted discussion
  1022. # [17:47] <fantasai> howcome: I want to suppress the headings on the pages in both page on the spread to be suppressed
  1023. # [17:48] <fantasai> peter: You want controls for spreads, not for numbered pages
  1024. # [17:48] <fantasai> Topic: Other
  1025. # [17:48] <fantasai> Bert: We can talk to XSLFO people. They've done this before
  1026. # [17:49] <fantasai> Bert: It might be more involved than just headers and footers.
  1027. # [17:49] <howcome> http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-last-line-avoid-property
  1028. # [17:49] * dbaron wonders if this is the one-more--hyphen---property
  1029. # [17:50] * Quits: ibrahima_ (qw3birc@128.30.52.28) (Ping timeout)
  1030. # [17:52] * Quits: parkjy (qw3birc@128.30.52.28) (Ping timeout)
  1031. # [17:52] <fantasai> Alex: Do we need a control for this property?
  1032. # [17:52] * Quits: rigo (rigo@128.30.52.169) (Client exited)
  1033. # [17:52] <fantasai> Alex: Couldn't we just always avoid it?
  1034. # [17:52] * dbaron thinks Antarctica should be Ant-arc-ti-ca
  1035. # [17:53] <fantasai> fantasai: Do we need a control for this, or can we just have the UAs be smart about it?
  1036. # [17:55] <fantasai> jdaggett: Do we need different values?
  1037. # [17:55] <fantasai> howcome: There are different policies among publishers. This is a control that's been asked for.
  1038. # [17:55] <dbaron> howcome: We can drop the 'always' value; it's not as important.
  1039. # [17:55] <fantasai> glazou: What happens if the last word is wider than the column?
  1040. # [17:56] <fantasai> howcome: It's an avoid, not a requirement
  1041. # [17:56] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
  1042. # [17:57] <fantasai> I think auto should be asking the UA to be smart and do something reasonable, not allowing anything....
  1043. # [17:58] <fantasai> Alex: spread should be on by default. Or maybe more than spread
  1044. # [17:58] * Quits: MoZ (540e3252@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  1045. # [17:58] * Joins: smfr (smfr@17.203.14.12)
  1046. # [18:00] <fantasai> Peter: Publishers do manual tweaking to avoid awkward breaks. Reset breaking for one particular word on one particular page
  1047. # [18:00] <fantasai> Peter: We're not going to do that in CSS
  1048. # [18:00] * sylvaing next topic: text-replace: "100" "1e2";
  1049. # [18:02] <fantasai> Peter describes some of the difficult aspects of pagination
  1050. # [18:02] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  1051. # [18:02] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
  1052. # [18:02] <fantasai> Peter: But if you tweak things at that level, you only satisfy layout for that particular output instance
  1053. # [18:03] <Bert> (Another way to reduce the ugliness in the example: This is just a / simple ex- / ample to show / Antarctica.)
  1054. # [18:03] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
  1055. # [18:03] <fantasai> Peter: It doesn't apply if you change any of the output environment parameters
  1056. # [18:03] <fantasai> Peter: By flipping this switch, it'll help some of the time and hurt some of the time.
  1057. # [18:03] <Kai> isn't it exactly the ability to output on different output environments that makes this feature necessary?
  1058. # [18:04] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
  1059. # [18:04] * tabatkins Bert, that requires more adaptive hyphenation, which is almost certainly too expensive for the web. Fine for print, though.
  1060. # [18:04] <fantasai> Peter: I read e-documents on this thing (iphone) all the time. And I change the font size all the time.
  1061. # [18:05] <fantasai> Peter: The author isn't thinking of that
  1062. # [18:05] * Joins: mjs (mjs@84.14.50.82)
  1063. # [18:05] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
  1064. # [18:06] <fantasai> Peter: I don't want us to target the weird thing that happens on my computer. I want to target the general problem.
  1065. # [18:07] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
  1066. # [18:07] <fantasai> Meeting closed.
  1067. # [18:07] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
  1068. # [18:07] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
  1069. # [18:07] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
  1070. # [18:07] * Quits: yuma_1986 (yuma_1985@84.14.50.82) (Quit: TakIRC)
  1071. # [18:08] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
  1072. # [18:08] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
  1073. # [18:09] * Quits: jdaggett (jdaggett@84.14.50.82) (Quit: jdaggett)
  1074. # [18:09] * Quits: joonho (joonholee@124.39.135.110) (Ping timeout)
  1075. # [18:09] * Quits: sylvaing (sylvaing@84.14.50.82) (Quit: sylvaing)
  1076. # [18:10] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
  1077. # [18:10] * Quits: MikeSmith (MikeSmith@84.14.50.82) (Ping timeout)
  1078. # [18:11] * Quits: mmielke (mmielke@84.14.50.82) (Ping timeout)
  1079. # [18:11] * Quits: tabatkins (tabatkins@84.14.50.82) (Ping timeout)
  1080. # [18:12] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  1081. # [18:13] * Quits: sbhan (qw3birc@128.30.52.28) (Quit: Page closed)
  1082. # [18:15] * Quits: timeless (timeless@84.14.50.82) (Quit: Leaving.)
  1083. # [18:15] <smfr> fantasai: is there any chance of getting minutes published at the end of each day?
  1084. # [18:16] * Joins: dsinger (dsinger@84.14.50.82)
  1085. # [18:16] <fantasai> smfr: I suppose I could do it if you really really really need it
  1086. # [18:16] <fantasai> smfr: It will take me probably around 4 hours
  1087. # [18:17] * Quits: freedom (freedom@84.14.50.82) (Ping timeout)
  1088. # [18:17] <smfr> fantasai: i'm curious about some of the discussion in the morning.
  1089. # [18:17] <fantasai> RRSAgent: pointer
  1090. # [18:17] <RRSAgent> See http://www.w3.org/2010/11/01-CSS-irc#T17-14-09
  1091. # [18:17] <fantasai> The IRC logs are available
  1092. # [18:17] <fantasai> see above
  1093. # [18:17] <smfr> ah excellent, thanks!
  1094. # [18:17] <smfr> that's fine
  1095. # [18:17] <fantasai> cool
  1096. # [18:18] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1097. # [18:19] * Parts: mollydotcom (mollyh@68.225.52.230)
  1098. # [18:21] * Joins: bradk_ (bradk@166.205.139.77)
  1099. # [18:21] * Quits: plinss_ (plinss@84.14.50.82) (Quit: plinss_)
  1100. # [18:22] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
  1101. # [18:22] * Joins: TabAtkinsTPAC (chatzilla@212.180.75.100)
  1102. # [18:22] <bradk_> Hello
  1103. # [18:23] * Quits: howcome (howcome@84.14.50.82) (Ping timeout)
  1104. # [18:23] <TabAtkinsTPAC> brad!
  1105. # [18:24] <bradk_> Howdee. Do you know where I can find the schedule of what you'll be discussing? And raw irrc log of discussion so far?
  1106. # [18:25] <smfr> RRSAgent: pointer
  1107. # [18:25] <RRSAgent> See http://www.w3.org/2010/11/01-CSS-irc#T17-22-43
  1108. # [18:26] <smfr> bradk_: ^^ irc log
  1109. # [18:27] <bradk_> Thanks
  1110. # [18:29] * Joins: jdaggett (jdaggett@93.158.28.68)
  1111. # [18:30] <bradk_> I also could not find the link to agenda wiki in my email. I know it must be there somewhere, but I must be searching for the wrong terms.
  1112. # [18:30] * Joins: mgylling (mgylling@212.180.75.100)
  1113. # [18:35] * Joins: mmielke (mmielke@93.158.30.183)
  1114. # [18:35] <smfr> TabAtkinsTPAC: i think a big unresolved transform issue is how they apply to inlines
  1115. # [18:36] <TabAtkinsTPAC> bradk_: the link to the agenda should be at the very beginning of the irc logs.
  1116. # [18:36] <TabAtkinsTPAC> smfr: Yes, indeed. Should we talk about that during the FXTF meeting on Thursday, or what?
  1117. # [18:37] <smfr> TabAtkinsTPAC: i think the css-wg is more likely to have useful input
  1118. # [18:37] <TabAtkinsTPAC> Ok. I'll push it on the agenda tomorrow.
  1119. # [18:37] <smfr> if it's later afternoon i could join
  1120. # [18:37] <TabAtkinsTPAC> The question is between transform-each-box or transform-bounding-box, right?
  1121. # [18:37] <TabAtkinsTPAC> kk
  1122. # [18:37] <smfr> options are:
  1123. # [18:38] <smfr> 1. disallow transforms on inlines
  1124. # [18:38] <smfr> 2. transform the bounding box
  1125. # [18:38] <smfr> 3. transform line boxes somehow
  1126. # [18:38] <TabAtkinsTPAC> kk
  1127. # [18:38] <smfr> 4. transform each bit like gecko does
  1128. # [18:38] <smfr> 5. maybe others
  1129. # [18:38] <TabAtkinsTPAC> Oh, right, (4) is different because of, frex, bidi mixes within a line?
  1130. # [18:39] <smfr> right
  1131. # [18:39] <smfr> i'm tempted to suggest `
  1132. # [18:39] <smfr> er, 1
  1133. # [18:39] <TabAtkinsTPAC> Yeah, that might be the best.
  1134. # [18:39] <smfr> authors can use inline-box if they have to
  1135. # [18:39] <arron> I think 1 would be best too
  1136. # [18:39] <TabAtkinsTPAC> We resolved on "just don't allow it on inline" for column spans in multicol, so it seems like we're comfortable with that.
  1137. # [18:40] <smfr> sweet
  1138. # [18:40] <TabAtkinsTPAC> smfr: Any thought on radial gradient canonical forms, while I have you here?
  1139. # [18:40] <smfr> no, i haven't studied the radial gradients spec yet
  1140. # [18:41] <smfr> saw your emails tho
  1141. # [18:41] <TabAtkinsTPAC> Did you read my email from yesterday?
  1142. # [18:41] <smfr> i saw it, then saw the second one so didn't read the first one entirely ;)
  1143. # [18:41] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  1144. # [18:42] <smfr> TabAtkinsTPAC: i don't quite grok the start point + angle form
  1145. # [18:43] <TabAtkinsTPAC> Okay, so here's how it works.
  1146. # [18:43] <smfr> you say the end point is the start rotated around the middle, but that's not true if there's an angle
  1147. # [18:43] <TabAtkinsTPAC> Right. What you do is, first, draw the reference line from the start point to the rotated end point.
  1148. # [18:43] * Joins: arron (arronei@166.205.141.3)
  1149. # [18:43] <TabAtkinsTPAC> Then, rotate the reference line *around the center of the box* by the angle.
  1150. # [18:43] <smfr> ok, so 2 things affect the final slant
  1151. # [18:43] <smfr> the points, and the angle
  1152. # [18:44] <TabAtkinsTPAC> Then the gradient start is the "point on the reference line where a line drawn perpeendicular intersects X cornere", etc.
  1153. # [18:44] <TabAtkinsTPAC> Yes, they work together, and have good behavior for their defaults.
  1154. # [18:44] <smfr> hmm, that sounds more complicated
  1155. # [18:45] <smfr> and it doesn't address the use of the explicit start/end points which places the gradient over some sub-rect
  1156. # [18:45] <TabAtkinsTPAC> Only because the combination of both a ref-line and an angle is strictly unnecessary. It's only specced that way so that the two cases are specific instances of a general case, and can be transitioneed together.
  1157. # [18:46] <TabAtkinsTPAC> smfr: I don't know if that's actually a use-case. I've never had to do that.
  1158. # [18:46] <TabAtkinsTPAC> And I made myself a gradient-image generator in PHP, so I used gradients pretty freely in designs.
  1159. # [18:48] * Joins: plinss_ (plinss@212.180.75.100)
  1160. # [18:48] <TabAtkinsTPAC> 95% of use-cases, I think, can be addressed solely with either an angle, or a box-cardinal direction.
  1161. # [18:48] <TabAtkinsTPAC> I'd be fine with just speccing both of those as separate functions, but if I can make a single function do them both without a lot of hassle, then I'd prefer to.
  1162. # [18:49] <TabAtkinsTPAC> I'd like to align whatever solution I do for linear gradients with a similar solution for radials, though. Radials are a much harder problem.
  1163. # [18:49] <TabAtkinsTPAC> Anyway, let me post that email to the list.
  1164. # [18:49] <smfr> k
  1165. # [18:53] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
  1166. # [18:54] <TabAtkinsTPAC> k, sent. now, off to dinner for a few hours.
  1167. # [18:55] <TabAtkinsTPAC> bradk_: Check out the email too. I think the model I propose for linear gradients has roughly equivalent power to yours, but more continuous behavior and less abstraction.
  1168. # [18:56] <TabAtkinsTPAC> bradk_: I still don't like the mode where you pretend that the angle is relative to a unit box and then transform it. But this one, where a bare angle is relative to a horizontal line and thus gives us the algebra-inspired behavior, still seems cool.
  1169. # [18:58] * Quits: tantek (tantek@70.36.139.128) (Quit: tantek)
  1170. # [18:58] * Quits: mmielke (mmielke@93.158.30.183) (Quit: mmielke)
  1171. # [19:07] * Joins: plinss__ (plinss@212.180.75.100)
  1172. # [19:07] * Quits: plinss__ (plinss@212.180.75.100) (Connection reset by peer)
  1173. # [19:07] * Joins: plinss__ (plinss@212.180.75.100)
  1174. # [19:07] * Quits: plinss_ (plinss@212.180.75.100) (Connection reset by peer)
  1175. # [19:34] * Quits: plinss__ (plinss@212.180.75.100) (Ping timeout)
  1176. # [19:42] * Joins: nimbupani (nimbupani@24.22.131.46)
  1177. # [19:42] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
  1178. # [19:56] * Quits: arron (arronei@166.205.141.3) (Quit: Colloquy for iPhone)
  1179. # [19:56] * Quits: arronei (arronei@131.107.0.83) (Ping timeout)
  1180. # [20:02] * Joins: arronei (arronei@131.107.0.91)
  1181. # [20:03] * Quits: jdaggett (jdaggett@93.158.28.68) (Ping timeout)
  1182. # [20:15] * Joins: bradk__ (bradk@166.205.138.206)
  1183. # [20:16] * Quits: bradk_ (bradk@166.205.139.77) (Ping timeout)
  1184. # [20:18] * Joins: tantek (tantek@67.218.98.105)
  1185. # [20:20] * Quits: tantek (tantek@67.218.98.105) (Quit: tantek)
  1186. # [20:21] * Joins: jdaggett (jdaggett@93.158.29.217)
  1187. # [20:21] * Quits: jdaggett (jdaggett@93.158.29.217) (Quit: jdaggett)
  1188. # [20:25] * Quits: bradk__ (bradk@166.205.138.206) (Quit: Signing Off. Buh-bye. )
  1189. # [20:28] * Parts: mgylling (mgylling@212.180.75.100)
  1190. # [20:44] * Joins: nimbupani (nimbupani@24.22.131.46)
  1191. # [20:46] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
  1192. # [21:25] * Joins: bradk_ (bradk@166.205.138.206)
  1193. # [21:49] * Joins: Peter` (peter@85.223.116.170)
  1194. # [21:50] * Quits: beverloo (peter@85.223.116.170) (Ping timeout)
  1195. # [21:54] <bradk_> Tab, I see it the other way around, where the keyword just turns off the bit that prevents the angle from stretching as the box stretches.
  1196. # [22:13] * Quits: bradk_ (bradk@166.205.138.206) (Quit: Signing Off. Buh-bye. )
  1197. # [22:25] * Quits: Ms2ger (Ms2ger@91.181.144.192) (Quit: nn)
  1198. # [22:32] * Quits: smfr (smfr@17.203.14.12) (Client exited)
  1199. # [23:31] * Quits: arronei (arronei@131.107.0.91) (Quit: arronei)
  1200. # [23:34] * Joins: arronei (arronei@131.107.0.94)
  1201. # Session Close: Tue Nov 02 00:00:00 2010

The end :)