/irc-logs / w3c / #css / 2011-07-26 / end

Options:

  1. # Session Start: Tue Jul 26 00:00:00 2011
  2. # Session Ident: #css
  3. # [00:00] <TabAtkins_> kojiishi: I think it may still be useful to have an option to not scale glyphs, as it may be ugly sometimes.
  4. # [00:00] <TabAtkins_> florian: Perhaps if you say "use-glyph no-scale", you just use exactly what's given back by the font, no measurement. It may be too big, but shrug. Then "use-glyph" will scale if they're too big, and "compress" will just always scale the full-size.
  5. # [00:01] <TabAtkins_> fantasai: Makes sense.
  6. # [00:01] <fantasai> ACTION fantasai: edit as above
  7. # 06[00:01] * RRSAgent records action 10
  8. # 06[00:01] * trackbot noticed an ACTION. Trying to create it.
  9. # [00:01] <trackbot> Created ACTION-358 - Edit as above [on Elika Etemad - due 2011-08-01].
  10. # [00:02] <TabAtkins_> RESOLVED: Remove the concept of glyph-size tolerance from this level of the spec.
  11. # [00:02] <jdaggett> whatever you spec out, you need to try it on some simple examples and include them in the description
  12. # [00:02] <TabAtkins_> fantasai: So for fonts with propotional, but not half-width glyphs, if you say "use-glyphs", should we just use the glyphs directly?
  13. # [00:03] <jdaggett> the markup should be easy and the implementation should be fairly easy
  14. # [00:03] <jdaggett> nat: yeah, you don't want multiple passes to support TCY
  15. # [00:03] <TabAtkins_> szilles: I think, since the user can say "no-scale" if they really don't want it, you should have a single default that works decently enough for everyone.
  16. # 03[00:04] * Joins: szilles (chatzilla@72.254.61.95)
  17. # [00:05] <TabAtkins_> kojiishi: The tolerance came in to address the common case where the TCY want to use two digits without scaling.
  18. # 02[00:08] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
  19. # [00:08] <TabAtkins_> nat: If we have different scaling values (depending on number of digits), it's too complicated for the value you get.
  20. # [00:08] <TabAtkins_> nat: I agree that it may be useful in some cases, as Koji says, but I don't think its' worthwhile to address.
  21. # [00:09] <TabAtkins_> nat: Koji brings up the possibility that some people may want to scale only when it looks terrible, and let it not scale if it's "almost there".
  22. # [00:09] <TabAtkins_> nat: But I don't think it's worth dealing with that explicitly. That should be something a UA could decide.
  23. # [00:09] <TabAtkins_> florian: Or we could go with steve's idea of adding a tolerance to scale.
  24. # [00:09] <TabAtkins_> szilles: I mainly just think we're spending too much time on this.
  25. # [00:10] <TabAtkins_> fantasai: And the default is the UA tries to do whatever it can to make things fit. No limitations.
  26. # 02[00:11] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  27. # [00:11] <TabAtkins_> nat: Moving on, it looks like you can omit the integer in "digits" etc. and it defaults to 2. I think it would be better to be explicit.
  28. # [00:11] <TabAtkins_> fantasai: Okay.
  29. # 03[00:12] * Joins: szilles (chatzilla@72.254.61.95)
  30. # [00:12] <TabAtkins_> kojiishi: You're not requiring an integer for "all", right?
  31. # [00:13] <bradk> cute
  32. # [00:13] <hober> bradk: i think you mean 'kawaii'
  33. # [00:13] <TabAtkins_> fantasai: Right.
  34. # [00:13] <TabAtkins_> nat: We should just make "all" be very simple. It does *all*.
  35. # [00:14] <szilles> Add Usecases for 2 or 3 digits in auto t-c-y and have an example with mix of digits and non-digits; e.g., "1.2"
  36. # [00:14] <florian> s/steve's idea of adding a tolerance to scale/steve's idea of adding a parameter to no-compress, rather than using tolerances/
  37. # [00:16] <TabAtkins_> fantasai: If you say "use-glyphs" and there's only a single char, the current spec says to use a full-width glyph if one is availab.e
  38. # [00:16] <TabAtkins_> nat: And I think you shouldn't do that.
  39. # [00:16] <TabAtkins_> nat: glyphs substituation may cause problems (undefined?)
  40. # 02[00:17] * Quits: Martijnc (Martijnc@84.192.44.100) (Quit: Martijnc)
  41. # [00:17] <TabAtkins_> nat: Are you supposed to scale up the glyphs to 1em, or what?
  42. # [00:17] <TabAtkins_> florian: i think we've said that TCY and text-transform interacts.
  43. # [00:18] <TabAtkins_> fantasai: Spec says that any text-transform features are turned off for combined text of more than 1 char.
  44. # [00:18] <TabAtkins_> florian: Then that's fine. You can use text-transform to get single large chars, but have smaller chars for more TCY.
  45. # [00:19] <TabAtkins_> fantasai: jdaggett you were saying that for text-transform we should write up proposals first and then discuss?
  46. # [00:19] <TabAtkins_> jdaggett: Yeah, I did some experiments. Spec says currently that you have to use the VR2 feature of the font, but in practice that doesn't really work.
  47. # [00:19] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Jul/0401.html
  48. # 03[00:19] * Joins: nmccully (nmccully@72.254.59.155)
  49. # [00:19] <TabAtkins_> s/text-transform/text-orientation/
  50. # [00:20] <TabAtkins_> jdaggett: In the post I summed up the key points:
  51. # [00:20] <TabAtkins_> jdaggett: Latin will rotate, greek and cyrillic won't, and there are many other cases where it's not clear that what exists is what you want.
  52. # [00:20] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Jul/0402.html
  53. # [00:21] <TabAtkins_> jdaggett: In discussion with Erik Mueller, we thought it mad emore sense to specify a property (possibly going into unicode) that says whether a character is upright or rotated.
  54. # 02[00:21] * Quits: nmccully (nmccully@72.254.59.155) (Client exited)
  55. # [00:21] <TabAtkins_> jdaggett: Then we can use that property to define the gray areas here.
  56. # 03[00:21] * Joins: stearns_ (qw3birc@128.30.52.28)
  57. # [00:21] <TabAtkins_> jdaggett: symbols, punctuation, currency, etc.
  58. # [00:21] <TabAtkins_> fantasai: That sounds reasonable.
  59. # [00:22] <TabAtkins_> jdaggett: I just don't think this can be a derived property from the existing values.
  60. # 02[00:22] * Quits: stearns (qw3birc@128.30.52.28) (Ping timeout)
  61. # [00:22] <TabAtkins_> fantasai: Agreed - until it's a unicode property, we'll have to have it be derived with a large list of exceptions.
  62. # [00:23] <TabAtkins_> jdaggett: And then the logic of text-orientation will be to use that property, then apply the "vert" opentype feature to the upright runs.
  63. # [00:23] <TabAtkins_> nat: And you do that so fonts which disagree with the feature can achieve that?
  64. # [00:23] <TabAtkins_> jdaggett: Yes.
  65. # [00:23] <TabAtkins_> nat: I'm comfortable with that.
  66. # [00:24] <TabAtkins_> jdaggett: This property effectively already exists, but it's just custom right now in different tables.
  67. # [00:24] <TabAtkins_> jdaggett: IE already has it (though clearly out of date; it doesn't do non-BMP). Webkit has a similar table, similarly wrong.
  68. # [00:24] <ChrisL> has Unicode consortium been asked to add this property?
  69. # [00:24] <TabAtkins_> jdaggett: It would be great to pull together our individual dbs and help make a proposal to unicode.
  70. # [00:25] <TabAtkins_> nat: InDesign has something similar too.
  71. # [00:25] <ChrisL> (I take what jdagett said to mean "not yet but we will")
  72. # 02[00:26] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
  73. # 06[00:26] * TabAtkins_ chrisl, I believe so, yes.
  74. # [00:26] <TabAtkins_> jdaggett: I don't think we need to get into the individual heuristics yet.
  75. # [00:26] <TabAtkins_> nat: When unicode didn't provide two codepoints for something that was two codepoints in shift_jis, we have to be able to differentiate.
  76. # [00:27] <TabAtkins_> nat: Some fonts have different designs for the two. In some fonts you want to rotate, and in others you don't.
  77. # [00:27] <TabAtkins_> fantasai: We can get info for Japanese fairly easily, but I'm concerned about other languages like Chinese where we don't have much if any information.
  78. # [00:28] <TabAtkins_> nat: It's different, and unfortuantely the standards are even more loose.
  79. # [00:28] <TabAtkins_> nat: We don't use font metrics, but it's very complicated to deal with this.
  80. # [00:29] <TabAtkins_> jdaggett: to handle that sort of thing, we could call out those specific codepoints and deal with those in a separate category.
  81. # [00:29] <TabAtkins_> jdaggett: So CSS3 can deal with japanese well, but the separation lets us make better rules for Chinese and such later.
  82. # [00:30] <TabAtkins_> szilles: You and I, jdaggett, have proposed being able to provide a delta on the unicode table.
  83. # [00:30] <TabAtkins_> jdaggett: I think it would be better to wait and propose the rpoeprty first, then went through and discussed how you might want to modify it.
  84. # [00:30] <TabAtkins_> szilles: Right; I brought it up as a reminder of the concept.
  85. # [00:31] <TabAtkins_> jdaggett: Right. it would be nice to eventually let authors say exactly what defaults they want ("never rotate english text"), so they didn't need to put a bunch of markup around specific areas.
  86. # [00:31] <TabAtkins_> szilles: It would also allow all the default tables out there to be incorporated.
  87. # [00:32] <TabAtkins_> fantasai: I have a concern that the rest of the draft (the layout parts) really ought to be stabilized somehow.
  88. # [00:33] <TabAtkins_> fantasai: We have a lot of work left to do on text-orientation, but I think the layout bits should be locked down and not held back by this work.
  89. # [00:34] <TabAtkins_> fantasai: Another month or two i can handle, but if this'll take us until next year, I'm concerned.
  90. # [00:34] <TabAtkins_> jdaggett: I don't think it'll take that long.
  91. # [00:34] <TabAtkins_> fantasai: One more item now.
  92. # [00:34] <TabAtkins_> fantasai: Sylvain was talking about the name of 'writing-mode' property.
  93. # 03[00:34] * Joins: szilles (chatzilla@72.254.61.95)
  94. # [00:34] <TabAtkins_> sylvaing: The writing-mode property says it defines block-progression (then why isn't in named "block-progression").
  95. # [00:35] <TabAtkins_> sylvaing: then it says that the writing mode is deifned by three properties, one of which is called "writing-mode", which is confusing.
  96. # [00:35] <TabAtkins_> fantasai: I think we shouldn't change the name, but if you have a better term...
  97. # [00:35] <TabAtkins_> sylvaing: There used to be a block-progression property.
  98. # [00:36] <TabAtkins_> fantasai: Yes, because at the time writing-mode was a shorthand that overrides "direction", which was a very bad thing. We've had this discussion a few times.
  99. # [00:36] <TabAtkins_> fantasai: And it's incompatible with SVG and IE6.
  100. # [00:36] <TabAtkins_> sylvaing: What is?
  101. # 06[00:36] * ChrisL all gaul is divided into three parts - belgica, acquiania, and gaul. I blame Ceasar for the original confusion
  102. # [00:36] <TabAtkins_> fantasai: We could call it block-progression, but then writing-mode would be an alias.
  103. # 06[00:37] * TabAtkins_ chrisl, the country was called "all gaul". i don't see the confusion!
  104. # [00:37] <TabAtkins_> dbaron: Is this a naming discussion, or a substantive one?
  105. # [00:38] <TabAtkins_> fantasai: Kinda both. Given legacy and other reasons, I think the name should stay, but I'm willing to change the terminology.
  106. # [00:38] <TabAtkins_> szilles: I agree that this would be better called "block-progression". But history/SVG means that it should stay consistent and be "writing-mode".
  107. # [00:39] <ChrisL> svg also uses the term 'block progression direction' (from xsl) btw
  108. # [00:39] <TabAtkins_> fantasai: I'd just like to avoid property aliases.
  109. # [00:39] <ChrisL> but it does use the writing-mode property, yes
  110. # 06[00:39] * jdaggett egads
  111. # [00:39] <TabAtkins_> dbaron: value aliases are much eaiser than property aliases.
  112. # 02[00:40] * Quits: jdaggett (jdaggett@110.4.235.34) (Quit: jdaggett)
  113. # [00:44] <bradk> meeting is over for today?
  114. # [00:44] <stearns_> no - just on break
  115. # [00:44] <ChrisL> i believe another 2.5 hours
  116. # [00:44] <bradk> OK, thanks
  117. # [00:44] <bradk> It sounded like everyone was heading out to go boating, but I guess that is later
  118. # [00:51] <JohnJansen> correct, Brad. That's at 7 tonight.
  119. # 02[00:56] * Quits: florian (florianr@72.254.81.111) (Ping timeout)
  120. # [01:01] <fantasai> ScribeNick: fantasai
  121. # [01:01] <fantasai> Topic: Gradients
  122. # [01:01] <fantasai> Tab: 3 issues to resolve
  123. # [01:01] <fantasai> Tab: First one is repeating gradients when the distance between the first and last stop approaches zero
  124. # 03[01:01] * Joins: vhardy (vhardy@72.254.57.220)
  125. # [01:02] <fantasai> TabAtkins: zw gradients are not a problem without repeating, but is a problem for repeating because you can't repeat them on the same point infinitely
  126. # [01:02] <fantasai> TabAtkins: Right now I punt on the issue by making repeating gradients requreid to have minimum 1px width
  127. # [01:02] <fantasai> TabAtkins: That guarantees we can tile the space like we should
  128. # [01:02] <fantasai> TabAtkins: Don't know if it's ideal, but it stops the problem of infinity
  129. # 06[01:02] * glazou loves when Tab explains that n * 0 is always 0 whatever is n :-)
  130. # [01:03] <fantasai> TabAtkins: Other possibility that preserves continuity is that when we hit zero width, we pick the average color you'd get
  131. # 06[01:03] * glazou loves when Tab explains that infinity / n is always infinity whatever is n :-D
  132. # 06[01:03] * ChrisL returns from steak break
  133. # [01:03] <fantasai> TabAtkins: Seems kinda complicated for an edge case, but I don't realy care, just want a decision
  134. # [01:03] <fantasai> TabAtkins: And to be consistent with svg
  135. # [01:03] <fantasai> Florian: Pixels aren't px
  136. # [01:03] <fantasai> TabAtkins: I'm fine with saying it's a hairline wide
  137. # [01:03] <fantasai> Florian: So you do fallback at device pixel
  138. # [01:04] <fantasai> Brian: WD says to use first oclor stop
  139. # [01:04] <fantasai> TabAtkins: Yeah, but that's not continuous behavior
  140. # [01:04] <ChrisL> device pixels is better. because svg scaling can mean that a 1px is really big
  141. # 02[01:04] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
  142. # [01:04] <fantasai> [fast talking]
  143. # [01:04] <fantasai> Brian: Non-repeating radial gradients folow last color stop rule
  144. # [01:05] <fantasai> dbaron: Butwith those you always fill the area outside with that color
  145. # [01:05] <fantasai> TabAtkins: As you approach the limit, you get that result
  146. # [01:05] <fantasai> Brian: So it's continuity issue.
  147. # [01:05] <fantasai> TabAtkins: I'm ok with either way, whatever way implementers would like to do, let's do
  148. # [01:05] <fantasai> shepazu: SVG, when it hits zero, says that nothing is rendered
  149. # [01:05] <fantasai> shepazu: That kinda punts on that
  150. # [01:06] <fantasai> shepazu: I don't know that SVG says anything about approaching zero
  151. # [01:06] <ChrisL> it does not, no. its either a zero bounding box or it isn't
  152. # [01:06] <fantasai> shepazu: The averaging thing doesn't seem like what ppl want to do
  153. # [01:06] <fantasai> fantasai: I think that makes the most sense; asyou zoom out that's what you'd get
  154. # [01:07] <fantasai> shepazu: It'd be mixed with other color.. start color end color harmonious with page
  155. # 02[01:07] * Quits: smfr (smfr@72.254.63.21) (Quit: smfr)
  156. # [01:07] <fantasai> TabAtkins: If you do 1px red blue and repeat it, it looks purple. If you make it smaller, can assume it'll look purple
  157. # 02[01:08] * Quits: anne (annevk@72.254.94.246) (Client exited)
  158. # [01:08] <fantasai> Brian: 1px seems too large to me. But making the spec normative at 1px, but allow better resolution
  159. # 03[01:08] * Joins: smfr (smfr@72.254.63.21)
  160. # [01:08] <fantasai> TabAtkins: So the clamp is at 1px or below.
  161. # 03[01:08] * Joins: nmccully (nmccully@192.150.22.5)
  162. # 03[01:08] * Joins: anne (annevk@72.254.94.246)
  163. # [01:08] <ChrisL> px or device pixel?
  164. # [01:08] <fantasai> Florian: So this would allow them to go to device pixel, but not force it
  165. # [01:08] <fantasai> CSSpx
  166. # [01:08] <ChrisL> eww
  167. # 02[01:08] * Quits: nmccully (nmccully@192.150.22.5) (Quit: Leaving.)
  168. # [01:08] <ChrisL> device pixels is better. because svg scaling can mean that a 1px is really big
  169. # [01:09] <fantasai> Brian: Do you want inconsistent rendering across zoom
  170. # [01:09] <fantasai> Brian: If you'll get purple pixels sooner at one zoom level than another zoom level
  171. # [01:10] <fantasai> ...
  172. # 06[01:10] * glazou waited for "infinity * 0 is undefined", here we are :-)
  173. # [01:10] <fantasai> TabAtkins: Gradients are a vector format in any case
  174. # [01:10] <fantasai> shepazu: If you zoom in until 1px is the whole screen, then what?
  175. # [01:10] <fantasai> TabAtkins: You're allowed to clamp at a smaller size
  176. # [01:11] <fantasai> Brad: Makes sense. Like with text you get better resolution as you zoom in.
  177. # [01:11] <ChrisL> <g transform="scale(1000,1000)"><rect width="1px" height="1px"fill="url(#gradient"/></g>
  178. # [01:11] <fantasai> TabAtkins: It ends up being a quality-of-implementation issue.
  179. # [01:11] <fantasai> dbaron: As the length of the repeating gradient approaches zero, you should average the color.
  180. # [01:12] <fantasai> Florian: Need to make sure it's not going to do that at 20px
  181. # [01:12] <dbaron> s/As the/You could just specify that as the/
  182. # [01:12] <ChrisL> I don't want the 1000 by 1000 device pixels rect above to be a solid colour
  183. # [01:12] <fantasai> plinss talks about billionths of a CSSpx
  184. # [01:13] <ChrisL> @shepazu could you read out my example please and make sure people understand it
  185. # [01:13] <fantasai> dbaron: I think it should be device pixels, because if you zoom out ...
  186. # [01:14] <fantasai> plinss: Say that the UA can substitute an average color if the gradient length is small [...]
  187. # 06[01:14] * shepazu ok ChrisL
  188. # 03[01:14] * Joins: florian (florianr@72.254.81.111)
  189. # 03[01:14] * Joins: mmielke (mmielke@72.254.87.0)
  190. # [01:15] <fantasai> fantasai: Just define what happens at zero. Everything above zero is handled by pixel-rounding, which we don't speicfy
  191. # [01:15] <fantasai> TabAtkins: So should I specify averaging color?
  192. # [01:16] <fantasai> dbaron: Need to specify color space to average in
  193. # [01:16] <fantasai> shepazu: So what happens when you zoom in?
  194. # [01:16] <fantasai> TabAtkins: That depends on implementation
  195. # 06[01:16] * sylvaing thought we were starting with the easiest issue
  196. # [01:16] <ChrisL> @dbaron yes, you do
  197. # [01:16] <fantasai> TabAtkins: If you zoom enough you hit rounding issues
  198. # [01:17] <ChrisL> @tab that is always the case. welcome to the world of non-financial computing which uses fixed precision arithmetic
  199. # [01:17] <fantasai> TabAtkins: I want to make sure ChrisL's case is handled
  200. # 06[01:17] * arronei wait till we get to the hard ones
  201. # 06[01:17] * ChrisL is glad
  202. # [01:17] <fantasai> TabAtkins: is allowed to handle, don't know if I can require it
  203. # [01:17] <fantasai> ..
  204. # [01:17] <fantasai> TabAtkins: I can't must without being precise
  205. # [01:18] <fantasai> shepazu: It's not as important to specify the behavior at 1px when ti's been defined as 1px, it's what the rendering is.
  206. # [01:18] <dbaron> I think Peter's suggestion was good.
  207. # [01:19] <fantasai> shepazu: Important part was ... as you zoom in that 1px width is now 50 pixels it should have the whole gradient
  208. # [01:19] <fantasai> shepazu: You can test that -- chris just wrote a test for that.
  209. # [01:19] <fantasai> shepazu: You haven't been dealing much with things like scale, but you're going to be, so you're going to run into this problem
  210. # [01:19] <ChrisL> css transforms
  211. # [01:20] <fantasai> Dean: We all know the implementers are going to do the best they can.
  212. # 06[01:20] * fantasai peterl should type his proposal
  213. # 06[01:20] * fantasai didn't catch the details
  214. # 06[01:20] * ChrisL missed the nanoPx also
  215. # [01:21] <fantasai> plinss: This is very simply specified.
  216. # [01:21] <fantasai> plinss: You try to not overspecify it.
  217. # [01:21] <ChrisL> s/gradient"/gradient)"
  218. # [01:22] <fantasai> plinss: When the UA has knowledge of the output resolution, it's allowed to substitute an average color for the repeating color when the device does not have the resolution to capture the resolution correctly.
  219. # [01:22] <fantasai> plinss: It lets everybody do the right thing to the best of their ability.
  220. # [01:22] <plinss_> s/the resolution correctly/the gradient correctly/
  221. # [01:23] <fantasai> RESOLVED: Accept plinss's proposal.
  222. # 06[01:23] * arronei I want my infinite resolution monitor
  223. # [01:23] <fantasai> TabAtkins: Image values is becoming divergent in implementation stability. Some features like gradients widely implemented, others have no impls or are just beginning implementation.
  224. # 06[01:23] * ChrisL is okay with that
  225. # [01:24] <fantasai> TabAtkins: In the interest of getting gradients unprefixed as soon as they're sufficiently stable, I'd like to either pull gradients out into a Gradients spec, or go through and kick a bunch of stuff into css4-images
  226. # 06[01:24] * ChrisL ^^ "that" meaning the resolution, not the divergence
  227. # [01:24] <fantasai> TabAtkins: pecifically, the image() function, the cross-fade() function, and image-* properties
  228. # [01:25] <ChrisL> which is larger, the bits you cut out or the bits you leave in?
  229. # [01:25] <fantasai> JohnJansen: I think pulling out Gradients would make it easier.
  230. # [01:25] <fantasai> sylvaing: If you move the others, you're still splitting the document.
  231. # [01:25] <fantasai> ChrisL, about equal
  232. # 06[01:25] * ChrisL oh
  233. # [01:26] <fantasai> fantasai: There's some things that should move just as fast as gradients. Also you need to define <image> type.
  234. # [01:26] <fantasai> TabAtkins: CR can reference WD, so it wouldn't delay CR, just REC
  235. # [01:26] <fantasai> TabAtkins: I just want to get Gradients to a point where we can kill prefixes
  236. # [01:27] <fantasai> TabAtkins: I don't care either way; WG decide for me.
  237. # [01:27] <sylvaing> http://dev.w3.org/csswg/css3-images/
  238. # 06[01:27] * ChrisL heads we win, tails you lose
  239. # [01:28] <fantasai> TabAtkins: So, we would keep 4.1. 4.3 is implemented in Mozilla, so keep that there. We can test it for now.
  240. # [01:28] <fantasai> TabAtkins: 4.2 and 4.4 would go
  241. # [01:28] <fantasai> TabAtkins: Gradients stay
  242. # [01:28] <fantasai> TabAtkins: 6 stays; object-* implemented already, rest is image sizing algorithm
  243. # [01:28] <fantasai> TabAtkins: Rest can be punted to level 4
  244. # [01:29] <ChrisL> I suggest splitting into css3 graidients and css3 images. because css4 images sounds like its years away, just from the name
  245. # [01:29] <fantasai> dbaron: Things without 2 impls should be at-risk
  246. # [01:29] <fantasai> ChrisL, we'll publishing Selectors 4 next month ;)
  247. # [01:30] <fantasai> TabAtkins: 9 is a separate issue we need to discuss
  248. # 06[01:30] * ChrisL my point about perception stands, regardless of any actual facts :)
  249. # [01:30] <fantasai> smfr: Seems we need cross-fade() to interpolate gradients
  250. # [01:31] <fantasai> Florian: We could pull back into 3 if it stabilizes before CR
  251. # [01:31] <ChrisL> @smfr you mean to interpolate as in a transition, not to draw the gradient?
  252. # [01:31] <fantasai> plinss: Any objections to splitting along the lines described?
  253. # [01:31] <smfr> ChrisL: my point is that interpolation of gradients and images should be in the same spec
  254. # [01:31] <fantasai> RESOLVED: Split css3-images as described
  255. # [01:32] <fantasai> TabAtkins: 3rd issue is about gradients directly
  256. # [01:32] <bradk> I am
  257. # [01:32] <fantasai> TabAtkins: I've been messing with keyword definitions for gradients
  258. # [01:33] <fantasai> TabAtkins: Right now you can specify linear gradients by keyword or angle
  259. # [01:33] <fantasai> TabAtkins: Some very informal polls on twitter, if you ask someone what a gradient with top should do, they agree with the spec
  260. # [01:33] <fantasai> TabAtkins: If you ask them about angles, they agree with the spec
  261. # [01:33] <fantasai> TabAtkins: If you ask them both at the same time, they say they should be the same, despite that being inconsistent.
  262. # [01:34] <fantasai> TabAtkins gives numbers
  263. # [01:34] <fantasai> TabAtkins: Given this, I think the angles are very easy to see, but the way keywords work right now is confusing
  264. # [01:34] <fantasai> TabAtkins: So I'm thinking we should drop keywords and work them out better for level 4
  265. # [01:34] <TabAtkins_> data:text/html,<div id=one></div><div id=two></div><style>div {margin: 50px; border: thick solid black;width: 520px;height: 300px;}#one {background: -webkit-linear-gradient(top left, red, white, blue);}#two {background: -webkit-linear-gradient(-60deg, red, white, blue);}</style>
  266. # [01:34] <fantasai> TabAtkins: We have an issue that corner-to-corner gradients, for example, are not sufficiently pretty.
  267. # [01:35] <bradk> he're's mine: http://www.bradclicks.com/cssplay/linear-gradient/corner-to-corner-gradient.png
  268. # [01:35] <fantasai> TabAtkins: The top one is what corner-to-corner gradients currently do
  269. # [01:35] <fantasai> TabAtkins: The gradient bands are perpendicular to the diagonal gradient line
  270. # [01:36] <fantasai> TabAtkins: But the lower picture is what people actually expect/want
  271. # [01:36] <fantasai> TabAtkins: The two are different by the angle being reflected over the line y=x
  272. # [01:36] <dbaron> data:text/html,<div class=one></div><div class=two></div><style>div {margin: 50px; border: thick solid black;width: 520px;height: 300px;}.one {background: -moz-linear-gradient(top left, red, white, blue);}.two {background: -moz-linear-gradient(-60deg, red, white, blue);}</style>
  273. # [01:36] <fantasai> TabAtkins: one is 30deg other is 60deg
  274. # 03[01:36] * Joins: ChrisL2 (ChrisL@128.30.52.169)
  275. # [01:36] <dbaron> (for those who don't want to use WebKit to look at it :-)
  276. # [01:37] <fantasai> Brad: Another way to say is that for corner to corner, the hypothetical midpoint connects the other two corners
  277. # 02[01:37] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  278. # [01:37] <fantasai> TabAtkins: With the current spec, the further the rectangle is from a square, the more it looks like a sideways gradient rather than a corner-to-corner one
  279. # [01:37] <fantasai> TabAtkins: Given this issue, I want to drop keywords for now and address them in level 4
  280. # [01:38] <fantasai> bradk: Keywords are the most popular way of doing this right now, mostly vertical or horizontal gradients.
  281. # [01:38] <fantasai> Brian: Instead of up top and bottom, use upwards and downwards and instead of left and right use leftward rightward
  282. # [01:39] <fantasai> Brian: And remove the paired keyword corner options
  283. # [01:40] <fantasai> plinss: If we do partial keyword option, then we're locking in our syntax and it'll be incompatible with our future syntax.
  284. # [01:40] <fantasai> plinss: We'll get into a situation where we dislike our legacy keywords and can't change them.
  285. # [01:40] <fantasai> TabAtkins: Could use a different function
  286. # [01:40] <fantasai> dbaron: Authors really want gradients. At some point we need to stop fiddling with it and declare it ready.
  287. # [01:40] <arno1> We could just have "horizontal" and "vertical" as keywords
  288. # [01:41] <fantasai> Florian: We're not throwing out all of it, just part of it
  289. # [01:41] <fantasai> Florian: just the part we don't agree on it.
  290. # [01:41] <dbaron> anne: We did that with border-radius, and by the time we got it sorted out they weren't popular anymore. :-)
  291. # [01:41] <fantasai> TabAtkins: We solve the cases we know we need now, get them unprefixed, then see if the remaining cases are useful enough to care
  292. # [01:42] <fantasai> Brad: the only gradient generators online use the keyword types right now, and because we changed the angle definition, you can't get something that works
  293. # [01:42] <fantasai> Brad: People use prefixed versions for years.
  294. # [01:42] <fantasai> TabAtkins: We're not going to use prefixed versions
  295. # [01:43] <fantasai> Brad: Because we changed meaning of degress, you can't make a backwards compat version
  296. # [01:43] <fantasai> TabAtkins: You write the prefixed versions with the old syntax, do unprefixed version with spec version
  297. # [01:44] <fantasai> various try to explain that prefixed versions aren't going to change; they'll change when they drop the prefix
  298. # [01:45] <smfr> Zakim: gavel
  299. # [01:45] <fantasai> smfr, you forgot to use a comma
  300. # [01:45] <fantasai> :P
  301. # 06[01:45] * hober taught my IRC client to tab-complete Zakim as "Zakim, " instead of "Zakim: " :)
  302. # [01:45] <fantasai> plinss: How vendors deal with them and their customers is up to them.
  303. # [01:46] <fantasai> Brad: I don't think we can pretend what we decide here is not going to have ramifications. If we don't have a committment that they won't do that... otherwise we wind up with something unusable
  304. # [01:46] <fantasai> TabAtkins: That's why nobody will do that.
  305. # [01:46] <fantasai> dbaron: We've done it plenty of times, but we probably wouldn't do it with this one
  306. # [01:46] <fantasai> Anne: It worked fine for border-radius, -moz-opacity, etc.
  307. # [01:47] <fantasai> Brad: I'd like to keep the keyword going and figure it out before we publish it.
  308. # [01:47] <fantasai> Arron: Do you have a problem with upwards/downwards/etc
  309. # [01:48] <fantasai> Brad: As plinss pointed out, it'll make it harder for us to get a consistent syntax later when we add corner-to-corner gradients
  310. # [01:48] <fantasai> TabAtkins: The future has potential. I'm confident I'm not blocking my ability to expand in the future.
  311. # [01:48] <fantasai> Brad: I don't see the syntax as being problematic.
  312. # [01:49] <fantasai> Brad: I don't think it needs to change.
  313. # 06[01:50] * fantasai thinks Tab's questions were skewed and doesn't think his conclusions were valid
  314. # [01:50] <fantasai> Brad: It's intuitive for a lot of people, and they've learned it, and do we really want to hold up the spec for this.
  315. # [01:51] <fantasai> ...
  316. # [01:51] <fantasai> smfr: I'm concerned about having multiple gradient functions. Do I need linear-gradient or corner-gradient?
  317. # [01:51] <fantasai> smfr: confusing
  318. # [01:52] <fantasai> TabAtkins: I think we can have a syntax that's different enough there won't be a parsing ambiguity
  319. # [01:53] <fantasai> Brad: "from top" would be close to current syntax and resolve ambiguity
  320. # [01:53] <fantasai> Brad: "left" -> "rightwards" is more different
  321. # [01:54] <fantasai> plinss: The question was about whether to drop the keywords, not about what they should be
  322. # [01:54] <fantasai> plinss: So do we drop the keywords, or go offline and figure it out
  323. # [01:54] <fantasai> TabAtkins: I want to drop the corner keywords
  324. # [01:55] <fantasai> plinss: Sounds like we're don't have consensus
  325. # [01:55] <fantasai> plinss: Take it to email/telecon
  326. # [01:55] <fantasai> plinss: Any other gradient issues?
  327. # [01:55] <fantasai> Brian: Premultiplied? Keep it don't keep it have options?
  328. # 02[01:55] * Quits: JohnJansen (johnjan@72.254.58.78) (Quit: Leaving.)
  329. # [01:56] <fantasai> TabAtkins: I think premultiplied produces most attractive gradients in common cases blending with transparent.
  330. # 02[01:56] * Quits: ChrisL2 (ChrisL@128.30.52.169) (Client exited)
  331. # [01:56] <fantasai> TabAtkins: I can go either way, depending on implementers
  332. # [01:56] <fantasai> fantasai: If you go other way, then make 'transparent' magic.
  333. # [01:57] <fantasai> TabAtkins: I don't want to make transparent magic.
  334. # [01:58] <fantasai> ?: Drop 'transparent' keyword, make everybody use rgba()
  335. # [01:58] <dbaron> Tab: If we're going to go non-premultiplied, then disallow use of 'transparent' and make everybody use rgba()
  336. # [01:58] <fantasai> fantasai: That's horrible. You're making the author do the work.
  337. # [01:59] <fantasai> ??: You have the same problem with transitions.
  338. # [01:59] <fantasai> fantasai: gradient from color to tranparent is very common use case
  339. # [01:59] <fantasai> smfr: Reality is that if we go with premultiplied we won't have it working correctly on Mac for another year or so
  340. # 03[01:59] * Joins: ChrisL (ChrisL@128.30.52.169)
  341. # [02:00] <fantasai> anne: If it's just a year, I say head for the future.
  342. # [02:00] <fantasai> Vincent: Example of where premultiplied looks better?
  343. # [02:00] <fantasai> TabAtkins: yellow to transparent, in premultiplied goes from yellow, fading to transparent
  344. # [02:01] <nimbupani> http://jsfiddle.net/rK9Pd/11/show/
  345. # [02:01] <fantasai> TabAtkins: in non-premultilied, goes through an ugly grayish greeny color
  346. # [02:01] <nimbupani> (check in webkit vs opera)
  347. # [02:01] <fantasai> TabAtkins: If you go red - transparent - blue, if you want to make it work correct in non-premultiplied, you have to write red, transparent-red, transparent-blue, blue, placing transparent-blue and transparent-red at the same spot in the gradient
  348. # [02:02] <fantasai> plinss: Why don't we want to do premultiplied?
  349. # [02:02] <fantasai> TabAtkins: It's not natively available on some platforms
  350. # 02[02:02] * Quits: glazou (glazou@72.254.87.99) (Client exited)
  351. # [02:02] <fantasai> smfr: We'd have to get libraries to add it
  352. # 03[02:03] * Joins: glazou (glazou@72.254.87.99)
  353. # [02:04] <fantasai> Brian: Alan Gresley was asking about non-premultiplied gradients because there are some cases that you'd want that result
  354. # [02:04] <fantasai> TabAtkins: You could simulate it by manually arc it through the color space, it's tricky, but doable, and a very uncommon case in comparison
  355. # [02:04] <fantasai> Brian: I had good results with Opera
  356. # [02:05] <fantasai> TabAtkins: With Opera and IE we'll have 2 impls, so let's stick with that.
  357. # [02:05] <fantasai> RESOLVED: Use premultiplied colors for gradients and transitions
  358. # [02:05] <fantasai> shepazu: At the outset of this effort, there was discussion about remaining compatible with SVG gradients.. was that abandoned?
  359. # [02:06] <fantasai> TabAtkins: No. SVG doesn't have alpha colors.
  360. # [02:06] <fantasai> shepazu: Talking about geometry
  361. # [02:06] <fantasai> TabAtkins: Yeah, I don't think that's useful. But I was going to talk tomorrow about using SVG paint servers in CSS or CSS gradients in SVG.
  362. # [02:06] <fantasai> shepazu: So an engine supporting both will have to support two different things.
  363. # [02:06] <fantasai> TabAtkins: Yes.
  364. # [02:07] <fantasai> plinss: Ok, let's discuss that tomorrow. Grids.
  365. # [02:07] <fantasai> Topic: Grids
  366. # [02:08] <fantasai> Phil: My name is Phil and I'm from MS.
  367. # [02:09] <fantasai> Phil: We recently published new editor's draft. Hoping none of it's controversial so we can go through it quickly.
  368. # [02:09] <fantasai> Phil: With one possible reduction in functionality in grid template property
  369. # 06[02:10] * sylvaing forgot to tell Phil that opening with the words 'not controversial' wakes everyone up
  370. # [02:10] <fantasai> Phil: specifically, assinging display types to grid pseudos
  371. # [02:11] <fantasai> ACTION Phil: Post notes to www-style or www-archive so they can be put in the minutes
  372. # 06[02:11] * trackbot noticed an ACTION. Trying to create it.
  373. # [02:11] <trackbot> Sorry, couldn't find user - Phil
  374. # 06[02:11] * RRSAgent records action 11
  375. # [02:11] <smfr> http://dev.w3.org/csswg/css3-grid-align/
  376. # [02:11] <fantasai> Phil: 7.2 covered explicitly defined grid cells, creating named grid cells
  377. # [02:11] <fantasai> Phil: You could place children of the grid into them. We're removing that
  378. # [02:11] <fantasai> Phil: Removing grid-stacking property, which said which layout this explicitly-defined grid cell would be using
  379. # 02[02:11] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
  380. # [02:12] <fantasai> Phil: The other mode it had was layer, which was the default layout type for a grid cell so items would layer on top of others
  381. # [02:12] <fantasai> Phil: When we presented that at MV ...
  382. # 02[02:12] * Quits: glazou (glazou@72.254.87.99) (Client exited)
  383. # [02:12] <fantasai> Phil: Talked about creating flows inside a grid cell
  384. # [02:13] <fantasai> Phil: And assigning display types to the grid cell
  385. # 03[02:13] * Joins: glazou (glazou@72.254.87.99)
  386. # [02:13] <fantasai> Phil: This was about creating presentation-specific structure through declaration of these grid cells, trying to remove concept form the grid layout spec
  387. # 06[02:13] * fantasai needs Das Keyboard
  388. # [02:14] <fantasai> Phil: We also added new paragraph about grid cell concept. We still have logicla notion of a grid cell, but it's just an alias syntax for referring to a region of the grid.
  389. # [02:14] <fantasai> Phil: But we're saying it's not stylable
  390. # [02:14] <fantasai> Phil: It's just a way to name a spot on the grid
  391. # [02:14] <fantasai> Phil: In section 6.4 , repeating columns and rows. e got some ffeedback that the name dlines syntax we had didn't make sense inside repeating syntax
  392. # [02:14] <fantasai> Phil: Since it defined that only the firs toccurance of the name would be honore, and purpose of repeat syntax is to replay the grid lines over
  393. # [02:15] <fantasai> Phil: Added issue as te whether to remove that ability from there
  394. # [02:15] <fantasai> Phil: Any feedback, send it, otherwise we'll remove
  395. # [02:15] <fantasai> Phil: We also had another isuse on the grammar, for grid columns and grid rows
  396. # [02:15] <fantasai> Phil: So we changed from ... to ...
  397. # [02:15] <fantasai> Phil: I'll let you figure it out; trust me the new one is better.
  398. # [02:16] <fantasai> Phil: Section 7.1 anonymous grid cells, we just added some language about relation between grid cells
  399. # [02:16] <fantasai> Phil: Now it's just logical container, what does it do to grid items inside.
  400. # [02:16] <fantasai> Phil: Define them as containing block
  401. # [02:16] <fantasai> Phil: And we said how they came ito being, added language defining dminesions of the grid cell etc.
  402. # [02:17] <fantasai> Phil: Next is explicitly defined grid cells, 7.2 is gone
  403. # [02:17] <fantasai> Phil: Defining grid cells with a template is still there
  404. # [02:17] <fantasai> Phil: Still use the ascii-art syntax
  405. # [02:17] <fantasai> Phil: Keeping around grid-cell proeprty, just don't have pseudo-element selector
  406. # [02:17] <fantasai> Phil: Can still define grid, and put things in it
  407. # [02:17] <fantasai> Phil: witht hat
  408. # [02:17] <fantasai> Phil: Section 7.5 automatic placement of grid items.
  409. # [02:18] <fantasai> Phil: It's no longer what we're thinking, so removed note
  410. # [02:18] <fantasai> Phil: ...
  411. # [02:18] <fantasai> Phil: Importance of automatic placement, some language about fixup of grid; it matches language in flexbox
  412. # [02:18] <fantasai> Phil: And we noted that if we don't have this fature, the fixup isn't useful
  413. # [02:18] <fantasai> Phil: Everything just gets dumped into first grid row. We're planning to leave in, so this is just an observation
  414. # [02:19] <fantasai> Phil: I just renamed section 8.1 .. size of grid items.
  415. # [02:19] <fantasai> Phil: Needs more work; need to specify box model calculations
  416. # [02:19] <fantasai> Phil: So if going to be stretched, questions like whta if you have a replaced element with intrinsic ratio ...........
  417. # [02:20] <fantasai> Phil: 10 calculating isze of grid tracks. Don't know if anyone is implementing, or thinking of implementing, but if so, we've published osme pseudo-code about sizing these bits of the grid.
  418. # [02:20] <fantasai> Phil: Some bugs in it still
  419. # [02:20] <fantasai> Phil: We'll update a few more times before pushing to WD
  420. # [02:20] <fantasai> Phil: Lastly all these changes captured in Appendix A
  421. # [02:20] <fantasai> Phil: That is everything we have changed. The biggest piece is obviously the inability now to create these grid cells that you can give a display inside to control how they layout their contents, does anybody have objections to removing concept from the spec?
  422. # [02:21] <fantasai> TabAtkins: Ok with it, majority of my use cases don't need it.
  423. # [02:21] <fantasai> TabAtkins: But if I ant to use this with regions, I need to nwo insert dummy elements to position them with grid ...
  424. # [02:21] <fantasai> TabAtkins: I greatly disagree that I should put dummy divs in my doc
  425. # [02:21] <fantasai> Markus: We think that should be defined somewhere other than grid
  426. # [02:22] <fantasai> TabAtkins: I hate junk put into your page for the sole purpose of styling.
  427. # [02:23] <fantasai> Tab tries to explain the difference between semantic markup and stylistic presentation to the MS folks
  428. # [02:23] <fantasai> Steve: Aren't templates a little bit of both?
  429. # [02:24] <fantasai> TabAtkins: As long as we keep in mind that we might want to do this more generalized in the future, then I'm cool.
  430. # [02:24] <bradk> If the CSS is creating the pseudo-elements, then conceivably more regions can be created to accomodate more content.
  431. # [02:24] <fantasai> Vincent: We have a resolution on this from the morning.
  432. # [02:24] <fantasai> ...
  433. # 06[02:25] * fantasai agrees with Tab
  434. # [02:25] <fantasai> Alex: One issue that we discovered ... which was that alignment in grid is currently different from alignment in flexbox
  435. # [02:26] <fantasai> Alex: What we discussed yesterday flexbox alignment, we kinda liked the idea of what grid is doing now. We're going to come up with a proposal that will make something consistent between the two.
  436. # [02:26] <fantasai> TabAtkins: Don't think they need to be different when both flexing and aligning stuff
  437. # [02:26] <fantasai> Markus: Q for Peter, we experiment with named lines, and ended up with very long strings.
  438. # [02:27] <fantasai> Markus: Is ther ea way to shortcut this somehow? Authoring becomes awkward.
  439. # [02:27] <fantasai> Phil: This example uses template
  440. # [02:27] <fantasai> Phil: It only takes one letter to name a position
  441. # [02:27] <fantasai> Phil: with named grid lines
  442. # [02:28] <fantasai> Phil: You end up putting 4 strings for each item that you had
  443. # [02:28] <fantasai> Phil: It gets a little verbose
  444. # [02:28] <fantasai> Phil: I think in practice if you have a grid, and have a large number of grid items
  445. # [02:29] <fantasai> Phil: And don't want to renumber them, you probably won't use named lines anyway
  446. # [02:29] <fantasai> TabAtkins: What wins if you use grid-rows, grid-columns
  447. # [02:29] <fantasai> Phil: If the grid cell exists, then it wins
  448. # 02[02:29] * Quits: bradk (bradk@99.7.175.117) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
  449. # [02:29] <fantasai> TabAtkins: What properties apply to grid templae ??
  450. # [02:30] <fantasai> ...
  451. # [02:30] <fantasai> Phil: You can only use ascii letters in grid template
  452. # [02:30] <fantasai> Florian: Disallowing punctuation doesn't disallow Chinese characters or accented characters...
  453. # [02:30] <fantasai> TabAtkins: Most reasonable layouts won't use 26, but last year I was looking at some very complicated layouts that were pushing it
  454. # [02:31] <fantasai> Arron: I had 180 in a layout I did
  455. # [02:31] <fantasai> TabAtkins: I think you should say any single character
  456. # [02:31] <fantasai> fantasai: grapheme cluster
  457. # [02:32] <fantasai> ...
  458. # [02:32] <dbaron> I wouldn't allow more than characters that are allowed to start identifiers.
  459. # [02:32] <fantasai> Phil: Would you use numbers ... ?
  460. # [02:34] <fantasai> dbaron: That includes most of Unicode except some ascii punctuation and stuff
  461. # [02:35] <fantasai> plinss: Where it gets unweildy with grid names, it's not so much where they're defined as where they're used
  462. # [02:35] <dbaron> template: "北北北北" "西中中东" "西中中东" "西中中东" "西南南东";
  463. # [02:35] <fantasai> ...
  464. # [02:36] <fantasai> plinss: I'm not concerned about the verbosity of the grid columns declaration
  465. # [02:36] <fantasai> plinss: I fyou line it up like that, I think it's readable
  466. # [02:36] <fantasai> plinss: Later when you do the grid-column ...
  467. # [02:36] <fantasai> Phil: You have up to for lines for positioning, so that's not too bad.
  468. # [02:36] <fantasai> Phil: But if you have a lot of grid items, that gets quite large
  469. # [02:36] <fantasai> plinss: Depends on how large your grid is
  470. # [02:37] <fantasai> Phil: No issues open on it, these are just some comments we got back
  471. # [02:37] <fantasai> plinss: Maybe you can have something that maps grid cells back into named grid lines
  472. # [02:37] <fantasai> plinss: Right now you can only do that with template.
  473. # [02:37] <fantasai> plinss: What if you could define a grid-cell "foo" defiend by these named lines
  474. # [02:38] <fantasai> plinss: You're not defining the grid template, so not single-letter names; use multi-character names
  475. # [02:38] <fantasai> Phil: We had ::grid-cell() pseudo that could do that
  476. # [02:38] <fantasai> Phil: It was tyleable enough that you coudl specify the ...
  477. # [02:38] <fantasai> Phil: Ultimately we pulled that out
  478. # [02:39] <fantasai> Phil: Anything else?
  479. # [02:39] <fantasai> TabAtkins: Alex and I were talking about dropping the 'fr' unit and just using the flex() function
  480. # [02:39] <fantasai> for flexbox
  481. # [02:40] <fantasai> Alex: Flex function can do everything fr unit can do in flex, but fr unit is just a shortcut for one of the use of flex function
  482. # [02:40] <dbaron> Isn't 'fr' a shortcut for one of the uses of the flex() function that requires all three arguments?
  483. # [02:40] <fantasai> Alex: In a grid fr is a basic of how it is calculated
  484. # [02:40] <fantasai> Alex: it would be .. also allow flex function in grid, in which case you could replace fr unit with it or have both
  485. # [02:41] <fantasai> Phil: right now we have minmax function, and cna mix that with min-content, max-content keywords
  486. # [02:41] <fantasai> Phil: Would we introduce flex() function there?
  487. # 06[02:41] * ed wonders what this meant: "TabAtkins: No. SVG doesn't have alpha colors." (most if not all browsers already support rgba/hsla syntax in svg colors/gradients, also there's stop-opacity in svg gradients)
  488. # [02:41] <fantasai> Alex: flex function has flexibility and preferred size
  489. # [02:41] <fantasai> Alex: ...
  490. # [02:41] <fantasai> Alex: Auto and flexibility at once.. produces the same calculation .. maximum, however preferred size of column based on content
  491. # 02[02:41] * Quits: glazou (glazou@72.254.87.99) (Ping timeout)
  492. # [02:42] <fantasai> Phil: There's just an issue we haven't resolved in the spec now
  493. # [02:42] <fantasai> Alex: For flexbox you don't specify 50 values for an items, so flex() being longer than a unit is not a big deal, but on a grid probably woudln't want to replace fr unitl with flex
  494. # [02:42] <fantasai> Alex: Make it even longer
  495. # [02:42] <fantasai> Alex: So if in grid definition fr is shortcut for flex(), we could kepe it for flex
  496. # [02:43] <fantasai> TabAtkins: I'm uncomfortable with two of us using different notions of flex
  497. # [02:43] <fantasai> dbaron: fr right now is equivalent to flex() on a basis of 0, and 0 is not the defautl for that third argument
  498. # [02:43] <fantasai> TabAtkins: I changed flex() ...
  499. # [02:44] <fantasai> TabAtkins: If you say flex(1), you start from zero
  500. # [02:44] <fantasai> TabAtkins: That's not what my spec says right now
  501. # [02:44] <fantasai> Alex: ...
  502. # [02:44] <fantasai> TabAtkins: Ok, we need to discuss this
  503. # [02:44] <fantasai> dbaron: I agree with Alex, but I think that's another reason to keep fr.
  504. # [02:44] <dbaron> s/.../the omitted preferred width should default to initial value/
  505. # [02:45] <fantasai> Arron: We submitted our proposal for floats and positioning, and we decided to split those. Alex volunteered me to do the editing
  506. # [02:45] <arronei> http://www.interoperabilitybridges.com/css3-positioning/
  507. # 03[02:45] * Joins: glazou (glazou@72.254.87.99)
  508. # [02:45] <fantasai> Arron: So you can take a look at it.Not too many differences from 2.1
  509. # [02:46] <fantasai> Arron: Most of it's what 2.1 says, with some little clarifications of handling our new value. So you won't see a lot of differences.
  510. # [02:46] <fantasai> Arron: Will jump straight to some changes.
  511. # [02:46] <fantasai> Arron: So our first change that we have here is page positioning.
  512. # [02:46] <fantasai> Arron: What this defines is a way to go straight for the initial containing block, much like fixed positioning does but without fixing on the page
  513. # [02:46] <fantasai> Arron: So size and positioning based on initial containing block
  514. # [02:46] <fantasai> Arron: It'll go all the way to the initial containing block, and positioning off of that box.
  515. # [02:47] <fantasai> Arron: That's the first part.
  516. # [02:47] <fantasai> smfr: How is it different from position: fixed
  517. # [02:47] <glazou> http://www.interoperabilitybridges.com/css3-positioning/ (trailing slash DOES matter)
  518. # [02:47] <fantasai> Rossen: If we create a region each the size of containing block, you want to have one positioned to the current region
  519. # [02:47] <fantasai> Rossen: Don't want to rely on how many relative and abspos elements in your ancestor chain
  520. # [02:48] <tantek> lol: http://twitter.com/getify/status/95648509319069696 <center> vs CSS
  521. # [02:48] <fantasai> Rossen: Different from position: fixed because in scrolling media, it's fixed to initial contianing block. So element scrolls along with the rest of the content
  522. # [02:48] <fantasai> Rossen: Similar to abspos content that has no positioned ancestor
  523. # [02:48] <fantasai> Rossen: Whereas fixed replicates
  524. # 06[02:48] * tantek notices Tab already responded to the bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=13361
  525. # [02:49] <fantasai> Rosse: Position page was specific to design so you can target only the current page, and unlike position: fixed; position: paged; elements ... you can position negatively, and you can overflow, and that's just fine, whereas fixed position that just clips
  526. # [02:49] <fantasai> dbaron: So it's positioned on the current page relative to its placeholder.
  527. # [02:51] <fantasai> fantasai: My concern is that you'll get a layout that makes sense on paged media, but breaks in scrolled. Opposite problem of fixed positioning.
  528. # 03[02:52] * Joins: jdaggett (jdaggett@202.221.217.73)
  529. # [02:52] <fantasai> fantasai: e.g. if you use this on a 15-page document, positioning 15-20 things throughout the document across the 15 pages, looks fine
  530. # [02:52] <fantasai> fantasai: Load that into a scrolled view, and everything piles on top of each other in the first screenful, and then scrolls away with the rest of the document empty
  531. # [02:53] <fantasai> ...
  532. # [02:53] <fantasai> Alex: We should have discusison of what are different aspects of paged media
  533. # [02:53] <fantasai> Alex: Some means it's non-interactive, you're on paper
  534. # [02:53] <fantasai> Alex: Some of it means you're paginated
  535. # [02:53] <fantasai> Alex: From pov of layout, it's tempting to apply paged media to regions. But it's not paged media
  536. # [02:54] <fantasai> Alex: Should we have a new media type?
  537. # [02:54] <fantasai> fantasai: I think so.
  538. # [02:54] <fantasai> Arron: What I"m trying to ge there is, we have this defintion right now, it may need more work as fantasai points out.
  539. # [02:55] <fantasai> Arron: What I'd like to do is put it up on W3C as an actual editor's draft, so we can start to shape something that works
  540. # [02:55] <fantasai> plinss: Anybody objecting?
  541. # [02:55] <fantasai> RESOLVED: Put CSS3 Positioning draft on dev.w3.org
  542. # [02:55] <fantasai> Arron: That's pretty much it. Please review once it's up
  543. # [02:56] <fantasai> plinss: Some flexbox issues to get back to?
  544. # [02:56] <fantasai> TabAtkins: Haven't had time.
  545. # [02:56] <fantasai> Alex: Directions and alignment; need to ...
  546. # 02[02:56] * Quits: sylvaing (sylvaing@72.254.84.129) (Quit: sylvaing)
  547. # [02:56] <fantasai> plinss: Meeting closed.
  548. # 03[02:56] * Parts: smfr (smfr@72.254.63.21)
  549. # 02[02:56] * Quits: glazou (glazou@72.254.87.99) (Quit: glazou)
  550. # 02[02:56] * Quits: kimberlyblessing (Kimberly@72.254.83.239) (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110713171652])
  551. # 02[02:56] * Quits: plinss_ (plinss@72.254.58.149) (Quit: plinss_)
  552. # 06[02:56] * fantasai is amazed we got through the agenda
  553. # 02[02:57] * Quits: nimbupani (Adium@72.254.58.68) (Quit: Leaving.)
  554. # 02[02:58] * Quits: vhardy (vhardy@72.254.57.220) (Quit: vhardy)
  555. # 02[02:58] * Quits: dbaron (dbaron@72.254.87.122) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  556. # 02[02:59] * Quits: arronei (arronei@72.254.94.7) (Ping timeout)
  557. # 02[02:59] * Quits: mmielke (mmielke@72.254.87.0) (Ping timeout)
  558. # 02[02:59] * Quits: florian (florianr@72.254.81.111) (Ping timeout)
  559. # 02[03:00] * Quits: cjon (cjon@72.254.88.135) (Ping timeout)
  560. # 02[03:00] * Quits: stearns_ (qw3birc@128.30.52.28) (Ping timeout)
  561. # 02[03:01] * Quits: alexmog (alexmog@72.254.58.5) (Ping timeout)
  562. # 02[03:03] * Quits: anne (annevk@72.254.94.246) (Quit: anne)
  563. # 02[03:03] * Quits: arno1 (arno@192.150.10.200) (Ping timeout)
  564. # 02[03:03] * Quits: tantek (tantek@72.254.95.69) (Quit: tantek)
  565. # 02[03:06] * Quits: TabAtkins_ (tabatkins@72.254.88.61) (Ping timeout)
  566. # 03[03:12] * Joins: karl (karlcow@128.30.54.58)
  567. # 02[03:16] * Quits: dino (dino@72.254.88.79) (Quit: dino)
  568. # 02[03:19] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  569. # 02[03:21] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
  570. # 03[03:24] * Joins: dino (dino@24.22.134.28)
  571. # 02[03:35] * Quits: kojiishi (kojiishi@72.254.88.159) (Ping timeout)
  572. # 03[04:26] * Joins: smfr (smfr@24.19.233.220)
  573. # 03[04:28] * Parts: smfr (smfr@24.19.233.220)
  574. # 03[05:16] * Joins: miketaylr (miketaylr@24.42.93.245)
  575. # 03[05:58] * Joins: jdaggett_ (jdaggett@202.221.217.73)
  576. # 02[06:05] * Quits: jdaggett_ (jdaggett@202.221.217.73) (Quit: jdaggett_)
  577. # 02[06:58] * Quits: miketaylr (miketaylr@24.42.93.245) (Quit: miketaylr)
  578. # 02[07:30] * Quits: boblet (u1921@88.198.6.68) (Ping timeout)
  579. # 02[07:32] * Quits: arronei_ (arronei@131.107.0.87) (Connection reset by peer)
  580. # 03[07:32] * Joins: arronei (arronei@131.107.0.87)
  581. # 03[07:49] * Joins: plinss_ (plinss@72.254.61.31)
  582. # 03[07:56] * Joins: glazou (glazou@173.160.172.65)
  583. # 02[07:56] * Quits: glazou (glazou@173.160.172.65) (Quit: glazou)
  584. # 03[07:59] * Joins: tantek (tantek@66.87.7.47)
  585. # 03[08:23] * Joins: dino_ (dino@67.170.79.14)
  586. # 02[08:26] * Quits: dino (dino@24.22.134.28) (Ping timeout)
  587. # 03[08:26] * dino_ is now known as dino
  588. # 03[08:29] * Joins: dino_ (dino@24.22.134.28)
  589. # 02[08:32] * Quits: dino (dino@67.170.79.14) (Ping timeout)
  590. # 03[08:32] * dino_ is now known as dino
  591. # 02[08:36] * Quits: tantek (tantek@66.87.7.47) (Quit: tantek)
  592. # 03[08:43] * Joins: konaya (konaya@83.251.16.72)
  593. # 02[08:44] * Quits: dino (dino@24.22.134.28) (Quit: dino)
  594. # 02[08:47] * Quits: plinss_ (plinss@72.254.61.31) (Quit: plinss_)
  595. # 03[08:49] * Joins: kojiishi (kojiishi@32.177.19.23)
  596. # 02[09:02] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
  597. # 02[09:33] * Quits: kojiishi (kojiishi@32.177.19.23) (Ping timeout)
  598. # 03[09:37] * Joins: kojiishi (kojiishi@166.187.112.8)
  599. # 03[09:42] * Joins: Jorrit (jorritv@88.131.66.80)
  600. # 02[09:42] * Quits: kojiishi (kojiishi@166.187.112.8) (Ping timeout)
  601. # 03[09:42] * Parts: Jorrit (jorritv@88.131.66.80)
  602. # 02[10:27] * Quits: jdaggett (jdaggett@202.221.217.73) (Quit: jdaggett)
  603. # 03[12:07] * Joins: Ms2ger (Ms2ger@91.181.57.248)
  604. # 02[13:07] * Quits: karl (karlcow@128.30.54.58) (Client exited)
  605. # 03[13:33] * Joins: karl (karlcow@128.30.54.58)
  606. # 02[13:33] * Quits: karl (karlcow@128.30.54.58) (Client exited)
  607. # 03[13:34] * Joins: karl (karlcow@128.30.54.58)
  608. # 03[13:52] * Joins: Martijnc (Martijnc@84.192.44.100)
  609. # 03[15:13] * Joins: miketaylr (miketaylr@206.217.92.186)
  610. # 03[15:42] * Joins: anne (annevk@72.254.83.34)
  611. # 03[15:56] * Joins: nimbupani (Adium@24.18.47.160)
  612. # 02[17:05] * Quits: nimbupani (Adium@24.18.47.160) (Quit: Leaving.)
  613. # 03[17:10] * Joins: oyvind (oyvinds@213.236.208.22)
  614. # 03[17:10] * Parts: oyvind (oyvinds@213.236.208.22)
  615. # 03[17:13] * Joins: dino (dino@24.22.134.28)
  616. # 02[17:22] * Quits: dsinger (dsinger@68.126.184.142) (Quit: dsinger)
  617. # 02[17:31] * Quits: Martijnc (Martijnc@84.192.44.100) (Connection reset by peer)
  618. # 03[17:43] * Joins: cjon (cjon@107.60.184.201)
  619. # 03[17:44] * Joins: JohnJansen (johnjan@98.237.249.23)
  620. # 02[17:48] * Quits: anne (annevk@72.254.83.34) (Quit: anne)
  621. # 02[17:48] * Quits: dino (dino@24.22.134.28) (Quit: dino)
  622. # 03[17:49] * Joins: Martijnc (Martijnc@84.192.44.100)
  623. # 03[17:51] * Joins: nimbupani (Adium@72.254.63.50)
  624. # 03[17:53] * Joins: anne (annevk@72.254.83.34)
  625. # 03[17:53] * Joins: plinss_ (plinss@72.254.86.78)
  626. # 03[18:01] * Parts: JohnJansen (johnjan@98.237.249.23)
  627. # 03[18:02] * Joins: dino (dino@72.254.59.25)
  628. # 03[18:04] * Joins: tantek (tantek@76.164.21.47)
  629. # [18:04] <tantek> heading over - ETA 10min
  630. # 03[18:05] * Joins: tpod (tpod@76.164.21.47)
  631. # 02[18:06] * Quits: tantek (tantek@76.164.21.47) (Quit: tantek)
  632. # 03[18:08] * Joins: arronei_ (arronei@72.254.56.67)
  633. # 03[18:08] * Joins: arno (arno@192.150.10.200)
  634. # 03[18:09] * Joins: bradk (bradk@99.7.175.117)
  635. # [18:10] <bradk> hello?
  636. # [18:11] <Ms2ger> Good evening
  637. # [18:11] <bradk> Is the meeting starting?
  638. # [18:12] <ed> in a moment
  639. # [18:12] <Ms2ger> tantek said he'd be there in a couple of minutes
  640. # 03[18:12] * Joins: sylvaing (sylvaing@72.254.56.201)
  641. # 02[18:12] * Quits: tpod (tpod@76.164.21.47) (Ping timeout)
  642. # [18:12] <plinss_> we'll be using the #fx channel for today's meeting
  643. # 03[18:13] * nimbupani is now known as nimbu
  644. # [18:13] <bradk> Please let me know when there is a skype call ready to connect.
  645. # 03[18:14] * Joins: tpod (tpod@66.87.2.135)
  646. # [18:15] <hober> me too :0
  647. # [18:15] <hober> err, :)
  648. # 03[18:16] * Joins: dbaron (dbaron@72.254.60.133)
  649. # [18:16] <tpod> How was the boat?
  650. # 03[18:16] * Joins: smfr (smfr@72.254.63.223)
  651. # [18:16] <anne> meeting is in #fx
  652. # [18:16] <sylvaing> Anne sank one Microsoft employee in the lake: success
  653. # [18:17] <sylvaing> Brad, i'm on Skype
  654. # 03[18:17] * Joins: TabAtkins_ (tabatkins@72.254.90.143)
  655. # [18:17] <tpod> anne: Pls set topic to say #fx
  656. # 03[18:18] * anne changes topic to 'logged at http://krijnhoetmer.nl/irc-logs/ today is in #fx'
  657. # 03[18:21] * Joins: szilles (chatzilla@72.254.90.148)
  658. # 03[18:21] * Joins: florian (florianr@72.254.59.60)
  659. # 03[18:22] * Joins: shans (qw3birc@128.30.52.28)
  660. # 03[18:25] * Joins: tantek (tantek@72.254.91.192)
  661. # 03[18:28] * Joins: alexmog (alexmog@72.254.92.49)
  662. # 02[18:30] * Quits: cjon (cjon@107.60.184.201) (Ping timeout)
  663. # 03[18:31] * Joins: dsinger (dsinger@17.197.32.11)
  664. # 02[18:34] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  665. # 02[18:42] * Quits: tpod (tpod@66.87.2.135) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
  666. # 03[18:42] * Joins: szilles (chatzilla@72.254.90.148)
  667. # 03[18:43] * Joins: ChrisL (ChrisL@128.30.52.169)
  668. # 02[18:46] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  669. # 03[19:01] * Joins: szilles (chatzilla@72.254.90.148)
  670. # 03[19:05] * Joins: shepazu (schepers@128.30.52.169)
  671. # 03[19:07] * Joins: stearns__ (anonymous@72.254.63.25)
  672. # 02[19:12] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  673. # 03[19:16] * Joins: szilles (chatzilla@72.254.90.148)
  674. # 02[19:35] * Quits: arronei_ (arronei@72.254.56.67) (Quit: arronei_)
  675. # 02[19:38] * Quits: arno (arno@192.150.10.200) (Ping timeout)
  676. # 02[19:43] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  677. # 03[19:53] * Joins: szilles (chatzilla@72.254.90.148)
  678. # 02[19:56] * Quits: alexmog (alexmog@72.254.92.49) (Ping timeout)
  679. # 03[20:02] * Joins: alexmog (alexmog@72.254.92.49)
  680. # 02[20:03] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  681. # 03[20:06] * Joins: szilles (chatzilla@72.254.90.148)
  682. # [20:07] <fantasai> dbaron: Is there a way to make it obvious when font-fallback happens? I considered adding Ahem to the fallback list, but it doesn't cover all of Unicode.
  683. # [20:07] <dbaron> fantasai, we have a new api for determining the fonts that actually got used for a range of text
  684. # [20:08] <dbaron> fantasai, beyond that, not sure
  685. # 02[20:16] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  686. # 06[20:19] * hyatt is really confused by positioned floats
  687. # 06[20:20] * hyatt doesn't get how something like bottom:0 would work
  688. # 02[20:20] * Quits: sylvaing (sylvaing@72.254.56.201) (Quit: sylvaing)
  689. # [20:20] <hyatt> when you don't even know the height of your block yet
  690. # 06[20:20] * hyatt doesn't get how computing static positions would work either
  691. # 03[20:27] * Joins: konaya (konaya@83.250.39.172)
  692. # 03[20:31] * Joins: szilles (chatzilla@72.254.90.148)
  693. # 02[20:39] * Quits: konaya (konaya@83.250.39.172) (Ping timeout)
  694. # 02[20:46] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  695. # 03[20:48] * Joins: szilles (chatzilla@72.254.90.148)
  696. # 03[21:03] * Joins: arno (arno@192.150.10.200)
  697. # 02[21:10] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  698. # [21:11] <dbaron> hyatt, well, yesterday I was the only one against it...
  699. # [21:11] <hyatt> seems like a different layout model to me
  700. # 06[21:11] * anne was not paying much attention
  701. # [21:11] <hyatt> like using left/top seems fine etc.
  702. # [21:11] <hyatt> but it's not really laying out at the same time a normal positioned object would
  703. # 03[21:12] * Joins: szilles (chatzilla@72.254.90.148)
  704. # [21:12] <hyatt> just trying to understand
  705. # [21:12] <hyatt> if it's 2-pass
  706. # [21:12] <hyatt> or
  707. # [21:12] <hyatt> i dunno
  708. # [21:12] <dbaron> it's either 2-pass and suboptimal or abitrary-N-pass and correct
  709. # [21:13] <dbaron> the draft hasn't specified which yet
  710. # 06[21:17] * fantasai wasn't paying much attention either
  711. # 06[21:17] * fantasai 's position on the positioning module is that whatever dbaron says is probably right
  712. # [21:17] <fantasai> :)
  713. # 02[21:18] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  714. # 03[21:19] * Joins: szilles (chatzilla@72.254.90.148)
  715. # 02[21:24] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  716. # [21:25] <hyatt> dbaron: is the expectation that positioned floats affect positioned descendants as well or only the normal flow
  717. # [21:25] <hyatt> there's some confusing sentence in there about block formatting contexts
  718. # [21:25] <hyatt> "A positioned-float box intersects with other elements in the same or other block formatting contexts. "
  719. # [21:25] <dbaron> positioned descendants of what?
  720. # [21:25] <hyatt> i have no idea what that sentence means
  721. # [21:26] <dbaron> (That said, my response should probably be: you're asking *me*?)
  722. # [21:26] <hyatt> "or other block formatting contexts"
  723. # [21:26] <hyatt> sounds like they expect it to actually affect things other than just your normal flow descendants
  724. # 03[21:26] * Joins: arron (Arron@24.17.123.244)
  725. # [21:26] <hyatt> but maybe they just mean normal flow objects that establish bfcs
  726. # [21:26] <hyatt> like overflow
  727. # [21:26] <hyatt> or columns
  728. # 02[21:35] * Quits: stearns__ (anonymous@72.254.63.25) (Quit: stearns__)
  729. # 02[21:37] * Quits: tantek (tantek@72.254.91.192) (Quit: tantek)
  730. # 02[21:37] * Quits: smfr (smfr@72.254.63.223) (Quit: smfr)
  731. # 02[21:38] * Quits: nimbu (Adium@72.254.63.50) (Client exited)
  732. # 02[21:38] * Quits: florian (florianr@72.254.59.60) (Ping timeout)
  733. # 02[21:39] * Quits: TabAtkins_ (tabatkins@72.254.90.143) (Ping timeout)
  734. # 03[21:39] * Joins: tpod (tpod@72.254.63.33)
  735. # 02[21:42] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
  736. # 03[21:46] * Joins: tpod_ (tpod@66.87.7.154)
  737. # 02[21:46] * Quits: tpod (tpod@72.254.63.33) (Ping timeout)
  738. # 03[21:46] * tpod_ is now known as tpod
  739. # 02[21:52] * Quits: Martijnc (Martijnc@84.192.44.100) (Quit: Martijnc)
  740. # 02[22:07] * Quits: anne (annevk@72.254.83.34) (Ping timeout)
  741. # 03[22:08] * Joins: nimbupani (Adium@72.254.63.50)
  742. # 03[22:15] * Joins: stearns (anonymous@72.254.63.25)
  743. # 02[22:31] * Quits: tpod (tpod@66.87.7.154) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
  744. # 02[22:38] * Quits: alexmog (alexmog@72.254.92.49) (Ping timeout)
  745. # 02[22:39] * Quits: Ms2ger (Ms2ger@91.181.57.248) (Quit: nn)
  746. # 03[22:39] * Joins: anne (annevk@72.254.83.34)
  747. # 03[22:39] * Joins: szilles (chatzilla@72.254.90.148)
  748. # 03[22:39] * Joins: tantek (tantek@66.87.7.154)
  749. # 03[22:40] * nimbupani is now known as nimbu
  750. # 03[22:42] * Joins: smfr (smfr@72.254.59.80)
  751. # 03[22:42] * Joins: TabAtkins_ (tabatkins@72.254.58.122)
  752. # 02[22:43] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  753. # 03[22:45] * Joins: ChrisL (ChrisL@128.30.52.169)
  754. # 03[22:47] * Joins: alexmog (alexmog@72.254.92.49)
  755. # 03[23:02] * Joins: szilles (chatzilla@72.254.90.148)
  756. # 02[23:05] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
  757. # 02[23:08] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
  758. # 03[23:38] * Joins: tantek_ (tantek@72.254.90.199)
  759. # 02[23:40] * Quits: tantek (tantek@66.87.7.154) (Ping timeout)
  760. # 03[23:40] * tantek_ is now known as tantek
  761. # 03[23:49] * Joins: szilles (chatzilla@72.254.90.148)
  762. # Session Close: Wed Jul 27 00:00:00 2011

The end :)