/irc-logs / w3c / #css / 2010-07-07 / end

Options:

  1. # Session Start: Wed Jul 07 00:00:00 2010
  2. # Session Ident: #css
  3. # [00:17] * Joins: shepazu (schepers@128.30.52.169)
  4. # [02:12] * Joins: CesarAcebal (acebal@85.152.177.64)
  5. # [02:13] * Quits: CesarAcebal (acebal@85.152.177.64) (Client exited)
  6. # [02:13] * Joins: CesarAcebal (acebal@85.152.177.64)
  7. # [02:13] * Quits: CesarAcebal (acebal@85.152.177.64) (Client exited)
  8. # [02:28] * Joins: miketaylr (miketaylr@24.42.95.108)
  9. # [02:32] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  10. # [03:07] * Quits: arronei (arronei@131.107.0.106) (Ping timeout)
  11. # [03:12] * Quits: miketaylr (miketaylr@24.42.95.108) (Ping timeout)
  12. # [03:13] * Joins: arronei (arronei@131.107.0.117)
  13. # [03:26] * Joins: miketaylr (miketaylr@24.42.95.108)
  14. # [04:35] * Joins: karl (karlcow@128.30.54.58)
  15. # [04:53] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  16. # [05:35] * Joins: karl (karlcow@128.30.54.58)
  17. # [05:35] * Quits: miketaylr (miketaylr@24.42.95.108) (Quit: Leaving...)
  18. # [05:53] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
  19. # [06:28] * Quits: Curt` (DorkeyDear@76.241.79.151) (Quit: Leaving)
  20. # [10:48] * Joins: lhnz (lhnz@188.223.83.48)
  21. # [11:37] * Joins: darkangel (darkangel@41.5.189.15)
  22. # [11:57] <darkangel> Hi. WRT issue #120 ... It seems that FF, Chrome, Opera, and IE9 all use a "hard" (non-gradient) transition in the middle of the arc ... I don't believe that this is a very useful rendering, and I agree with the current draft that a gradient should be used. As Boris pointed out, inset/outset borders are also affected.
  23. # [15:11] * Joins: miketaylr (miketaylr@38.117.156.163)
  24. # [16:47] * Joins: Curt` (DorkeyDear@76.241.79.151)
  25. # [17:21] <fantasai> darkangel: Thanks for the feedback. I agree with you that gradient transitions should be used, however the WG decided to leave the color transition undefined for CSS3.
  26. # [17:28] <fantasai> darkangel: Not enough implementors were willing to commit to implementing a gradient
  27. # [17:29] <fantasai> darkangel: And there were complaints that there should be a more precise definition, etc.
  28. # [17:30] <fantasai> darkangel: I'm hoping we can add a gallery of pretty corner joins as an appendix to inspire implementations to use a gradient. :P But no normative prose requiring it
  29. # [17:38] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  30. # [17:38] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  31. # [17:38] <RRSAgent> logging to http://www.w3.org/2010/07/07-CSS-irc
  32. # [17:39] <plinss_> zakim, this will be style
  33. # [17:39] <Zakim> ok, plinss_; I see Style_CSS FP()12:00PM scheduled to start in 23 minutes
  34. # [17:39] <plinss_> rrsagent make logs public
  35. # [17:39] <plinss_> rrsagent, make logs public
  36. # [17:39] <RRSAgent> I have made the request, plinss_
  37. # [17:52] * Joins: sylvaing (sylvaing@76.104.131.10)
  38. # [17:53] * Joins: bradk (bradk@67.188.133.45)
  39. # [17:57] <Zakim> Style_CSS FP()12:00PM has now started
  40. # [17:58] <Zakim> +dsinger
  41. # [17:58] * Joins: oyvind (oyvinds@213.236.208.22)
  42. # [17:58] * Joins: dsinger (dsinger@67.218.107.132)
  43. # [17:58] <dsinger> zakim, mute dsinger
  44. # [17:58] <Zakim> sorry, dsinger, muting is not permitted when only one person is present
  45. # [17:58] <Zakim> +[plinss]
  46. # [17:59] <dsinger> zakim, mute dsinger
  47. # [17:59] <Zakim> dsinger should now be muted
  48. # [17:59] * dsinger good morning!
  49. # [18:01] * Joins: dethbakin (dethbakin@17.246.18.190)
  50. # [18:01] <dsinger> Zakim, who is here on time?
  51. # [18:01] <Zakim> I don't understand your question, dsinger.
  52. # [18:01] <dsinger> Zakim, who is here?
  53. # [18:01] <Zakim> On the phone I see dsinger (muted), [plinss]
  54. # [18:01] <Zakim> On IRC I see dethbakin, dsinger, oyvind, bradk, sylvaing, RRSAgent, Zakim, Curt`, miketaylr, darkangel, lhnz, karl, arronei, shepazu, Bert, krijn, fantasai, anne, plinss_, plinss,
  55. # [18:01] <Zakim> ... trackbot, tabatkins, Hixie, jgraham
  56. # [18:02] <Zakim> +[Microsoft]
  57. # [18:02] <Zakim> +bradk
  58. # [18:02] <Zakim> + +1.650.214.aaaa
  59. # [18:03] <plinss_> zakim, aaaa is tabakins
  60. # [18:03] <Zakim> +tabakins; got it
  61. # [18:03] <Zakim> +[Apple]
  62. # [18:03] <dethbakin> Zakim, Apple has dethbakin
  63. # [18:03] <Zakim> +dethbakin; got it
  64. # [18:04] <Zakim> +smfr
  65. # [18:04] * Joins: smfr (smfr@72.25.91.23)
  66. # [18:04] * Joins: arron (arronei@166.205.141.36)
  67. # [18:04] * Joins: TabAtkins_ (tabatkins@216.239.45.4)
  68. # [18:04] <smfr> Zakim, who's here
  69. # [18:04] <Zakim> smfr, you need to end that query with '?'
  70. # [18:04] <smfr> Zakim, who's here?
  71. # [18:04] <Zakim> On the phone I see dsinger (muted), [plinss], [Microsoft], bradk, tabakins, [Apple], smfr
  72. # [18:04] <Zakim> [Apple] has dethbakin
  73. # [18:04] <Zakim> On IRC I see TabAtkins_, arron, smfr, dethbakin, dsinger, oyvind, bradk, sylvaing, RRSAgent, Zakim, Curt`, miketaylr, darkangel, lhnz, karl, arronei, shepazu, Bert, krijn,
  74. # [18:04] <Zakim> ... fantasai, anne, plinss_, plinss, trackbot, tabatkins, Hixie, jgraham
  75. # [18:05] <Zakim> +SteveZ
  76. # [18:05] <TabAtkins_> ScribeNick: TabAtkins_
  77. # [18:05] <bradk> If Z knew it was a query, why require a question mark?
  78. # [18:05] <smfr> indeed
  79. # [18:06] <Zakim> +sylvaing
  80. # [18:06] <plinss_> z has very picky and somewhat pointless syntax
  81. # [18:06] <smfr> also, why does the bridge need to tell me it's a customized computex something conferencing system every time I dial in?
  82. # [18:06] <TabAtkins_> The bridge is very vain.
  83. # [18:06] * Joins: szilles (chatzilla@67.180.186.242)
  84. # [18:06] <Zakim> +Bert
  85. # [18:08] <Zakim> -sylvaing
  86. # [18:08] <Zakim> +sylvaing
  87. # [18:08] <TabAtkins_> plinss_: Any new agenda items?
  88. # [18:08] <TabAtkins_> plinss_: Seems like no.
  89. # [18:08] <TabAtkins_> plinss_: Test suite updates?
  90. # [18:09] <fantasai> I am not able to call in
  91. # [18:10] <TabAtkins_> TabAtkins_: I was able to get a contractor hired to help out elika with reviewing tests.
  92. # [18:10] <TabAtkins_> plinss_: Okay, open issues.
  93. # [18:10] <TabAtkins_> plinss_: 53 is still open
  94. # [18:10] <plinss_> http://wiki.csswg.org/spec/css2.1#issue-53
  95. # [18:10] <arronei> I'm only on IRC today. But on my end I am getting a list of test cases that are invalid.
  96. # [18:10] <arronei> I will send out that list by the end of the week.
  97. # [18:11] <TabAtkins_> plinss_: Daniel was getting feedback from Thunderbird people, I believe he did.
  98. # [18:11] <TabAtkins_> plinss_: They said they were okay with ignoring justification in preformatted text, I believe.
  99. # [18:11] * Quits: dsinger (dsinger@67.218.107.132) (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
  100. # [18:11] <fantasai> I'm not ok with ignoring justification
  101. # [18:11] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Jul/0055.html
  102. # [18:13] <TabAtkins_> Elika's suggestion is that we respect justification everywhere (even preformatted), but not on lines that end in a hard wrap.
  103. # [18:13] <TabAtkins_> TabAtkins_: Bonus of that is that it's a pretty nice simplification.
  104. # [18:14] <TabAtkins_> bradk: Elika's suggestion makes sense.
  105. # [18:14] <TabAtkins_> plinss_: But if you're preformatted, differing numbers of spaces may not be the proper width anymore.
  106. # [18:14] <fantasai> Because that's what you asked for
  107. # [18:14] <fantasai> you asked for preformatted, not monospace
  108. # [18:15] <fantasai> you didn't ask for grid layout
  109. # [18:15] <fantasai> you asked to preserve whitespace and to justify
  110. # [18:15] <fantasai> if you didn't mean justify, then don't ask for it
  111. # [18:16] <TabAtkins_> plinss_: My concern is that justification is inherited, so the justification might come up from further in the chian.
  112. # [18:17] <TabAtkins_> bradk: What about word-spacing? Different fonts are formatting too.
  113. # [18:17] <fantasai> Then add pre { text-align: initial; } to the defualt UA style sheet
  114. # [18:17] * Joins: dsinger (dsinger@17.197.23.122)
  115. # [18:18] <Zakim> +[Apple.a]
  116. # [18:18] <dsinger> zakim, [Apple] has dsinger
  117. # [18:18] <Zakim> +dsinger; got it
  118. # [18:18] <TabAtkins_> plinss_: word-spacing applies to every character individually, so I think that's okay.
  119. # [18:18] <Zakim> -dsinger
  120. # [18:18] <fantasai> no it doesn't it only applies to spaces
  121. # [18:18] <TabAtkins_> TabAtkins_: I don't think that distinction is justified. You can use fonts with varying ratios of character to space widths in pre text, and get all sorts of differing renderings.
  122. # [18:18] <fantasai> letter-spacing applies to every grapheme cluster individually
  123. # [18:19] <fantasai> word-spacing only applies to spaces
  124. # [18:20] <TabAtkins_> szilles: So the question is what properties should apply in pre text?
  125. # [18:20] <TabAtkins_> TabAtkins_: I think they all should.
  126. # [18:20] * plinss_ actually said letter-spacing, error in minutes
  127. # [18:20] * sylvaing is reminded to track down the weird issue of non-breaking spaces having a fixed width even when justified in some browsers
  128. # [18:21] * fantasai sylvaing: :)
  129. # [18:21] * Joins: matiassingers (matiassing@86.52.111.83)
  130. # [18:22] <fantasai> pre should mean "preserve white space", not "turn off random features to more closely approximate plaintext sans formatting"
  131. # [18:22] <fantasai> imo
  132. # [18:22] <TabAtkins_> Bert: Justification can move linebreaks around, which isn't compatible with preformatted text.
  133. # [18:22] <fantasai> Bert: how can it move linebreaks around?
  134. # [18:22] <TabAtkins_> TabAtkins_: Elika's suggestion is to only justify soft-wrapped lines. A preformatted text block with only hard breaks won't justify.
  135. # [18:22] <fantasai> Bert, justification happens *after* linebreaking
  136. # [18:23] * TabAtkins_ elika -> apparently TeX can do that with its more complex justification.
  137. # [18:23] <TabAtkins_> plinss_: So we've talked about this for a while. Anyone being convinced?
  138. # [18:23] <fantasai> Ok, true, but if you're soft-wrapping, you're already handing over line-breaking to the layout engine anyway
  139. # [18:24] <fantasai> hard line breaks don't move
  140. # [18:24] <Bert> (Fantasai, if you are allowed to stretch/compress word spaces, you may want to chose your line breaks such that adjoining lines both stretch or both shrink. TeX does that. Also to avoid "rivers" of white.)
  141. # [18:25] <TabAtkins_> TabAtkins_: I like Elika's suggestion. It seems to respect the restrictions of preformatted text while still letting authors do things complex if they want.
  142. # [18:25] <fantasai> (Bert, that's cool, but as I said, hard line breaks don't move, and soft ones are UA-determined anyway)
  143. # [18:25] <fantasai> (The UA may choose breaks to reduce the raggedness of a ragged edge, too, for example)
  144. # [18:26] <TabAtkins_> plinss_: I guess I'm okay with it. I'm slightly concerned if this changes anything in existing preformatted text.
  145. # [18:26] <fantasai> (In which case a different UA with the same fonts and containing block width won't give the same soft breaks)
  146. # [18:26] <fantasai> peter, then I recommend to add the pre rule to the default UA stylesheet
  147. # [18:26] <Bert> (Yes, and so I agree with your proposal. :-) )
  148. # [18:26] * Joins: nimbupani (nimbupani@24.22.131.46)
  149. # [18:26] <fantasai> peter, because most pre text in the wild is probably in <pre> elements
  150. # [18:26] <TabAtkins_> smfr: Webkit doesn't do text-align:start in <pre> by default.
  151. # [18:27] <TabAtkins_> szilles: Can someone make some tests and find out what is actually used? Because there might be a lot of files out there that depend on the current behavior (e.g. no justification in preformatted text).
  152. # [18:28] * Joins: jSepia (jsepia@200.120.141.173)
  153. # [18:28] * Parts: jSepia (jsepia@200.120.141.173)
  154. # [18:28] <fantasai> szilles: preformatted text does not wrap
  155. # [18:28] <fantasai> szilles: it's only pre-wrap that you'd have to check
  156. # [18:33] * fantasai should have noticed earlier that Skype is blocked here and tried to get a phone card to work
  157. # [18:34] * fantasai has no idea what you all are discussing
  158. # [18:34] <TabAtkins_> szilles: Since hittin pre-wrap is such an edge case any way, I don't know if it's worth making it act weird with justification.
  159. # [18:34] * TabAtkins_ sorry, fantasai, I'm catching up on minutes.
  160. # [18:35] <TabAtkins_> [discussion about letter-spacing, and whether or not it preserves formatting - it only does so in monospace text]
  161. # [18:36] <TabAtkins_> bradk: If we punt, there's a chance we could be locked in by implimentations.
  162. # [18:37] <TabAtkins_> plinss_: Thunderbird was "okay" with preventing justification in pre-wrap text (which they use in composing mail messages).
  163. # [18:37] <TabAtkins_> plinss_: I like Elika's proposal, I just don't know if we want to bring up a new behavior for 2.1.
  164. # [18:38] <TabAtkins_> szilles: The way we usually fix these is to spec what is done today, and later come up with a new value for the new behavior if we still want it.
  165. # [18:39] <fantasai> What's done today doesn't match the spec anyway
  166. # [18:39] <fantasai> Also, if we lock ourselves in here, the author has no control
  167. # [18:39] <fantasai> szilles, What new control do you want to introduce in CSS3? text-align: justify-no-I-really-mean-it?
  168. # [18:40] <szilles> Elika, no I would introduce a "pre-wrap-justify" value
  169. # [18:40] <TabAtkins_> plinss_: Maybe someone could write up a matrix of a text-align, whitespace, and point out where we've got gaps in either the spec or reality?
  170. # [18:40] <TabAtkins_> s/plinss_/dsinger/
  171. # [18:40] <dsinger> that was me
  172. # [18:40] <fantasai> szilles: That's ridiculous. It mixes up white-space with text-alignment and justification in addition to it's already mixed up text-wrap and ws-collapse behavior.
  173. # [18:40] <TabAtkins_> TabAtkins_: I can do that.
  174. # [18:41] <fantasai> szilles: We coudl define different behavior for values of text-justify
  175. # [18:41] <fantasai> szilles: auto means pre doesn't justify, anything else means it does
  176. # [18:41] <TabAtkins_> plinss_: Next is 101 on dbaron, he's not here.
  177. # [18:41] <plinss_> http://wiki.csswg.org/spec/css2.1#issue-110
  178. # [18:41] <bradk> \me deferring to mailing list for pre issue
  179. # [18:42] <bradk> doh
  180. # [18:44] <szilles> Elicka, I would agree that your argument about justify and pre-wrap makes sense. My argument is that, currently, this is so much an edge case that requiring changes in all implementations is not reasonable at this time and could inhibit getting out of CR.
  181. # [18:44] <TabAtkins_> http://lists.w3.org/Archives/Public/www-style/2010May/0483.html
  182. # [18:44] <TabAtkins_> TabAtkins_: After talking with Elika, I'm happy with presenting my last proposal to the list, from May. ^^^
  183. # [18:45] <TabAtkins_> TabAtkins_: Module the minor changes suggested by Brad and Peter Moulder in the immediate responses.
  184. # [18:45] <darkangel> fantasai: Thanks for your response. I just don't like the idea that different vendors may implement the transition differently, leading to inconsistent appearance. That, and the current implementation is rather ugly. Is it technically difficult to render a gradient in this position? Say for example, a linear diagonal gradient from the one end of the arc to the other?
  185. # [18:46] <fantasai> darkangel: you really don't want a linear gradient. You want a conical one. And that's apparently hard to get in current APIs
  186. # [18:46] <TabAtkins_> TabAtkins_: i think boris is the only implementor who has given the issue 110 proposal serious feedback so far, so anyone else who would be working on table-stuff that could look at it would be great.
  187. # [18:47] <plinss_> http://wiki.csswg.org/spec/css2.1#issue-138
  188. # [18:47] <TabAtkins_> plinss_: Anyone reviewed this?
  189. # [18:47] <Zakim> -smfr
  190. # [18:48] <Zakim> +smfr
  191. # [18:48] * fantasai would like to know where teh whole proposal lives
  192. # [18:48] * fantasai also thinks getting iterop on the static position will be way harder than pre justification :)
  193. # [18:51] <TabAtkins_> TabAtkins_: Summary is that floats will follow the relpos of their parent, even if their parent is an inline that is officially broken around it.
  194. # [18:52] <TabAtkins_> szilles: I'm somewhat concerned about floats being treated as part of the content as a general principle.
  195. # [18:52] <fantasai> What does 'opacity' do?
  196. # [18:52] <TabAtkins_> szilles: That is, what about things like footnotes?
  197. # [18:52] * matiassingers is now known as matiassingers|afk
  198. # [18:52] <fantasai> If 'opacity' affects the float, then I think relpos should also affect the float
  199. # [18:52] <fantasai> They're both filtery effects
  200. # [18:53] <fantasai> graphical transformations, whatever
  201. # [18:55] <TabAtkins_> TabAtkins_: Floats are a weird half-space, where they are out-of-flow for some things and in-flow for some things. It's a different space entirely from abspos and footnotes, which move completely independently of the "surrounding content".
  202. # [18:55] <TabAtkins_> plinss_: Who has to change for this?
  203. # [18:56] <TabAtkins_> TabAtkins_: IE8 appears to use the suggested behavior. Gecko is close. Opera and Webkit are substantially different.
  204. # [18:56] <TabAtkins_> TabAtkins_: I'll bug Hyatt and try to bug Opera people about the feasability of this today.
  205. # [18:56] <plinss_> http://wiki.csswg.org/spec/css2.1#issue-140
  206. # [18:56] <TabAtkins_> Bert: I haven't managed to do #140 yet.
  207. # [18:56] <TabAtkins_> Bert: Next week seems possible.
  208. # [18:57] <TabAtkins_> http://wiki.csswg.org/spec/css2.1#issue-140
  209. # [18:58] <TabAtkins_> http://wiki.csswg.org/spec/css2.1#issue-142
  210. # [18:58] <TabAtkins_> Bert: Same thing. But I think maybe Elika was supposed to do this one? I can't remember if it was this one or another that she said she would do.
  211. # [18:59] <TabAtkins_> plinss_: 158, I don't think we'll do that in 4 minutes.
  212. # [18:59] <fantasai> Bert, I'm doing 120 for you
  213. # [18:59] <TabAtkins_> TabAtkins_: Plus, there was a *lot* of feedback on that over the weekend which I haven't been able to process yet.
  214. # [18:59] * matiassingers|afk is now known as matiassingers
  215. # [18:59] <plinss_> http://wiki.csswg.org/spec/css2.1#issue-167
  216. # [19:01] <TabAtkins_> [summary of the proposal]
  217. # [19:02] * Parts: dsinger (dsinger@17.197.23.122)
  218. # [19:02] * Joins: dsinger (dsinger@17.197.23.122)
  219. # [19:03] * bradk abstains from voting on this one
  220. # [19:03] * TabAtkins_ me too
  221. # [19:03] * fantasai thinks dbaron should be consulted
  222. # [19:03] <TabAtkins_> plinss_: Any testcases on what implementations do on this one?
  223. # [19:05] <Zakim> -sylvaing
  224. # [19:05] <Zakim> -[Microsoft]
  225. # [19:05] <Zakim> -smfr
  226. # [19:05] * Quits: smfr (smfr@72.25.91.23) (Quit: smfr)
  227. # [19:05] <Zakim> -[Apple]
  228. # [19:05] <Zakim> -[plinss]
  229. # [19:05] <Zakim> -tabakins
  230. # [19:05] <Zakim> -SteveZ
  231. # [19:05] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
  232. # [19:05] <Zakim> -[Apple.a]
  233. # [19:06] <Zakim> -bradk
  234. # [19:06] <Zakim> -Bert
  235. # [19:06] <Zakim> Style_CSS FP()12:00PM has ended
  236. # [19:06] <Zakim> Attendees were dsinger, [plinss], [Microsoft], bradk, +1.650.214.aaaa, tabakins, dethbakin, smfr, SteveZ, sylvaing, Bert, [Apple]
  237. # [19:06] * Parts: dethbakin (dethbakin@17.246.18.190)
  238. # [19:07] * Quits: dsinger (dsinger@17.197.23.122) (Quit: dsinger)
  239. # [19:07] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
  240. # [19:11] * Quits: arron (arronei@166.205.141.36) (Ping timeout)
  241. # [19:15] * matiassingers is now known as matiassingers|afk
  242. # [19:15] * matiassingers|afk is now known as matiassingers
  243. # [19:53] <darkangel> fantasai: A diagonal linear gradient looks pretty good (mockup in Photoshop) – why not use it, at least until the graphics libraries are improved?
  244. # [20:18] * matiassingers is now known as matiassingers|afk
  245. # [20:20] * matiassingers|afk is now known as matiassingers
  246. # [20:21] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
  247. # [20:21] * Joins: arron (arronei@166.205.143.242)
  248. # [20:23] * Joins: smfr (smfr@17.203.14.12)
  249. # [20:23] <smfr> can anyone point me to the css wg's bugzilla?
  250. # [20:48] * Zakim excuses himself; his presence no longer seems to be needed
  251. # [20:48] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  252. # [20:58] * matiassingers is now known as matiassingers|afk
  253. # [21:02] * matiassingers|afk is now known as matiassingers
  254. # [21:44] * Quits: smfr (smfr@17.203.14.12) (Client exited)
  255. # [21:48] * matiassingers is now known as matiassingers|afk
  256. # [22:02] * Quits: sylvaing (sylvaing@76.104.131.10) (Quit: sylvaing)
  257. # [22:21] * matiassingers|afk is now known as matiassingers
  258. # [22:38] * matiassingers is now known as matiassingers|afk
  259. # [22:38] * matiassingers|afk is now known as matiassingers
  260. # [22:42] * Quits: arron (arronei@166.205.143.242) (Quit: Colloquy for iPhone)
  261. # [22:42] * Joins: arron (arronei@166.205.143.242)
  262. # [22:46] * Quits: darkangel (darkangel@41.5.189.15) (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])
  263. # [22:52] * Quits: arron (arronei@166.205.143.242) (Quit: Colloquy for iPhone)
  264. # [23:01] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
  265. # [23:06] <fantasai> tabatkins: Did you want to track flexbox issues in Tracker or the wiki? 'Cuz Alex seems to be very interested in sorting that out, and it's probably a good idea now that you're actively working on the spec
  266. # [23:07] <tabatkins> I have no idea how to use the Tracker, but I do know how to use the wiki. So, based solely on that, wiki.
  267. # [23:11] <fantasai> Tracker is pretty straightforward. If you look around, I'm sure you can figure it out. Its main advantages are integration with IRC and the mailing lists. It's main disadvantages are sub-optimal web interface and only editable by WG members.
  268. # [23:16] <fantasai> Another advantage is a better archiving story: issues each have their own page, so the URL is stable even when they're purged from the currently active list
  269. # [23:17] * fantasai thinks about usage patterns
  270. # [23:17] <fantasai> I think I tend to use Tracker for pre-LCWD issues
  271. # [23:18] <fantasai> for that very reason. They let me focus on what's open and ignore what's closed
  272. # [23:19] <fantasai> But for LC comments, I track those in a plaintext file, since I want the whole list, open and closed, available.
  273. # [23:20] * fantasai keeps that file in CVS, along with the spec
  274. # [23:24] * Joins: nimbupani (nimbupani@24.22.131.46)
  275. # Session Close: Thu Jul 08 00:00:00 2010

The end :)