/irc-logs / w3c / #css / 2013-02-05 / end

Options:

  1. # Session Start: Tue Feb 05 00:00:00 2013
  2. # Session Ident: #css
  3. # [00:00] <sylvaing> florian, we already have concrete proposals. some of them are even implemented. last, i don't understand the need to rush this. confusion and lack of consensus are not good reasons to speed up
  4. # [00:03] * Joins: mollyholzschlag (~mholzsch@public.cloak)
  5. # [00:04] <florian> sylvaing, Point taken. It is a bit harder to read the mood of the wg via irc, so I'll use that as an excuse.
  6. # [00:08] * plinss_away is now known as plinss
  7. # [00:12] * florian falls asleep
  8. # [00:16] * Quits: florian (~florian@public.cloak) (Ping timeout: 60 seconds)
  9. # [00:20] * Joins: plinss_ (~plinss@public.cloak)
  10. # [00:20] * Quits: tantek (~tantek@public.cloak) (Client closed connection)
  11. # [00:21] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 60 seconds)
  12. # [00:22] <dbaron> sylvaing, do you have animations issues you want us to talk about?
  13. # [00:23] <sylvaing> the main one for a f2f is the ongoing discussion about animations in the cascade
  14. # [00:23] <sylvaing> I believe the action was on dean to explain WebKit's model?
  15. # [00:23] <fantasai> TabAtkins, see also http://lists.w3.org/Archives/Public/www-style/2008Mar/0308.html
  16. # [00:23] <dbaron> sylvaing, we'll have jdaggett's microphone/speaker device tomorrow, but we don't have it today
  17. # [00:24] <dbaron> sylvaing, so we're inclined to postpone any call-in things to tomorrow/Wednesday
  18. # [00:24] <sylvaing> fine by me
  19. # [00:24] <TabAtkins_> ScribeNick: TabAtkins_
  20. # [00:25] * Joins: glazou (~glazou@public.cloak)
  21. # [00:25] <TabAtkins_> Rossen: We resolved to drop background-repeat:space from level 3.
  22. # [00:25] <TabAtkins_> Rossen: But that's something that IE and Opera actually support.
  23. # [00:25] <TabAtkins_> Rossen: I was looking at border-image-repeat, which we dont' support.
  24. # [00:25] <TabAtkins_> Rossen: So I'd like to separate the issue. I'm okay with dropping the border-image-repeat, but not background-image-repeat.
  25. # [00:25] * mollyholzschlag remember we break at 5PM AZ time tomorrow, 4PM CA/WA/OR time
  26. # [00:26] <TabAtkins_> Bert: I think both of them do "the right thing" - the background is spaced to the edges, border-image is away from the edges. Both cases are "the right thing", but they're inconsistent.
  27. # [00:26] <TabAtkins_> fantasai: That's probably alright.
  28. # [00:26] <TabAtkins_> plinss: So do we still want to drop the border-image value? Or mark it as at-risk?
  29. # [00:27] <dbaron> Bert: the more we keep, the better
  30. # [00:27] <dbaron> dbaron: the more we drop, the better
  31. # [00:27] <TabAtkins_> Rossen: We have three impls, actually - webkit does background-repeat:space too.
  32. # [00:28] * Joins: tantek (~tantek@public.cloak)
  33. # [00:28] <TabAtkins_> Rossen: If dropping it is done simply to move the spec forward, I'm for it.
  34. # [00:28] <TabAtkins_> Rossen: But I don't see a reason to drop the already-implemented part.
  35. # [00:28] * sylvaing with three implementations we should be renaming, not dropping....*cough*
  36. # [00:29] * fantasai we could rename it to space-between, to be consistent with flexbox :)
  37. # [00:29] <TabAtkins_> fantasai: We could mark it at-risk
  38. # [00:29] <TabAtkins_> plinss: Andn put the reasons in the spec.
  39. # [00:29] * sylvaing fantasai, wait to teach me about trolling...
  40. # [00:29] <TabAtkins_> s/space-between/space-around/
  41. # [00:30] * TabAtkins_ It was for border-image-repeat. ^_^
  42. # [00:30] * sylvaing ah, never mind then. rock on with your bad selves
  43. # [00:30] <TabAtkins_> RESOLVED: Keep background-repeat:space, drop border-image-repeat:space.
  44. # [00:33] <fantasai> Topic: Tab Atkins presents fantasai's crazy proposal from the break wrt placeholder styling
  45. # [00:33] <TabAtkins_> s/crazy//
  46. # [00:33] <fantasai> TabAtkins: Idea was to do the placeholder pseudo-class, do fill-opacity, and ignore the rest of it for later
  47. # [00:33] <fantasai> TabAtkins: Those two would solve all the problems we have right now.
  48. # [00:33] <fantasai> dbaron: How do you just "do" fill-opacity?
  49. # [00:33] <fantasai> dbaron: One of the questions wrt fill-opacity is, if we eventually do fill and fill-opacity for text,
  50. # [00:33] * Joins: liam (liam@public.cloak)
  51. # [00:33] <fantasai> dbaron: presumably there's some tradeoff where in some cases we do the color property, and others use text
  52. # [00:34] <fantasai> TabAtkins: No, we just always use 'fill', and 'fill' defaults to 'currentColor'. SVG is already OK with adding a UA style rule setting it to black for SVG elements.
  53. # [00:34] <fantasai> fantasai: It would default to black, but initial value would be currentColor.
  54. # [00:35] <stearns> if we do weird things for :placeholder pseudo-class, will there then be an expectation that this hack should work for other pseudo-classes?
  55. # [00:35] <fantasai> dbaron: we don't even know if the new inheriting behavior of currentColor is Web-compatible.
  56. # [00:35] * Quits: mollyholzschlag (~mholzsch@public.cloak) ("sleeping computer is sleeping")
  57. # [00:36] <fantasai> TabAtkins: Could fix it in 'fill' in multiple ways. Could use 'auto' as the initial value. If necessary.
  58. # [00:36] <fantasai> TabAtkins: But don't have to worry about 'fill' right now. Just have to know there's a path forward. And deal with 'fill-opacity' now.
  59. # [00:36] <fantasai> dbaron: If we don't do that model, and we have a different one where...
  60. # [00:37] <fantasai> dbaron: using fill in some cases and color in others...
  61. # [00:37] <fantasai> TabAtkins: Is there a reason to do that?
  62. # [00:37] <fantasai> dbaron: Are we sure we can do the other thing compatibly?
  63. # [00:37] <fantasai> dbaron: Two models for dealing with fallback
  64. # [00:37] * Joins: mollyholzschlag (~mholzsch@public.cloak)
  65. # [00:37] <fantasai> dbaron: One is fill always works, but defaults to color.
  66. # [00:38] * Parts: mollyholzschlag (~mholzsch@public.cloak) (mollyholzschlag)
  67. # [00:38] <fantasai> dbaron: other is fill has a "pass" value that says, don't do any filling, just use color like you used to.
  68. # [00:38] <fantasai> fantasai: Ah, and in that case 'fill-opacity' wouldn't work.
  69. # [00:38] <fantasai> SimonSapin: What's the difference?
  70. # [00:38] <fantasai> TabAtkins: First one could be incompatible with Web, while second is not. Second prevents you from using fill-opacity in general, because if you use pass value, it fill-opacity wouldn't apply.
  71. # [00:39] <fantasai> dbaron: Also kindof odd to have fill-opacity but not fill
  72. # [00:39] <fantasai> TabAtkins: But plan to add fill soon
  73. # [00:39] <fantasai> dbaron: Don't think it's high enough priority
  74. # [00:39] <fantasai> TabAtkins: Ok...
  75. # [00:40] <fantasai> TabAtkins: [...]
  76. # [00:41] <fantasai> TabAtkins: Alternatively, add foreground-opacity, which does opacity for my contents but not for me.
  77. # [00:41] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
  78. # [00:41] <fantasai> TabAtkins: Reasonable thing people have asked for.
  79. # [00:41] <fantasai> szilles: Doesn't that fall out of composition?
  80. # [00:41] <fantasai> SimonSapin: That's only for backgrounds.
  81. # [00:42] <fantasai> fantasai: Seems somewhat reasonable, but I would be less comfortable doing that with a week's notice than adding just fill-opacity....
  82. # [00:43] <fantasai> Bert: I'm not sure what I want, but going back a step, because we were talking about :placeholder
  83. # [00:43] <fantasai> Bert: The :placeholder idea seems bad idea to me UI-wise
  84. # [00:44] <dbaron> s/:placeholder/placeholder/
  85. # [00:44] <fantasai> Bert: Either should leave it to UAs, or alternatively go all the way and give people alternative ways to show it
  86. # [00:45] <fantasai> Bert: Don't have control over tooltip styling either
  87. # [00:47] <glenn> opacifying?
  88. # [00:47] <fantasai> fantasai: Just to go back a bit, one of my concerns with having both pseudo-class and pseudo-element is that authors will be confused when to use which one and how they interact. Because when there's only one, the cascade is obvious, but when both are there, rules intended to style the placeholder could interact in unexpected ways depending on which selector was used.
  89. # [00:48] <fantasai> smfr: Why add fill-opacity, avoids pseudo-element?
  90. # [00:48] <fantasai> TabAtkins: That and, it's useful generally.
  91. # [00:48] <fantasai> [Explanation of why opacity is desired styling of placeholders: it preserves contrast no matter which colors/backgrounds author chose, while dimming the contrast slightly to distinguish from actual value]
  92. # [00:49] <fantasai> s/preserves/preserves having/
  93. # [00:50] <fantasai> >______<
  94. # [00:50] <glenn> contrasty?
  95. # [00:51] <Rossen> contracity!
  96. # [00:51] <SimonSapin> constratificationement
  97. # [00:51] <fantasai> Topic: Writing Modes
  98. # [00:52] <fantasai> http://dev.w3.org/csswg/css3-writing-modes/#text-combine-horizontal
  99. # [00:52] <dbaron> should we wait for jdaggett?
  100. # [00:53] <jdaggett> how about tomorrow for writing modes?
  101. # [00:53] <jdaggett> i haven't looked over the changes in that section yet
  102. # [00:53] <fantasai> Rossen gives a history of various values for text-combine-horizontal
  103. # [00:53] <fantasai> http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/#text-combine-horizontal
  104. # [00:54] <fantasai> Rossen: Lot of feature creep for not much benefit.
  105. # [00:54] <fantasai> Rossen: most of the content that requires this has 2 or at most 4 ascii digits
  106. # [00:54] <fantasai> Rossen: That's 90% use case
  107. # [00:54] <jdaggett> oh well, guess i'll just review the discussion and reopen issues if need be
  108. # [00:54] <fantasai> Rossen: Decision was to retract back on adding explicit markup around horizontal bits in order to style individually
  109. # [00:54] <fantasai> Rossen: Which seems like underkill
  110. # [00:55] <fantasai> Rossen: Proposal is to go back to what is that we really want to accomplish here.
  111. # [00:55] * sylvaing underkill?
  112. # [00:55] <fantasai> Rossen: Original idea was pretty good, want to have automatic display of horizontal-in-vertical
  113. # [00:55] <fantasai> Rossen: If most widely used cases is 2-4 digit ascii numbers, then let's do that, have that be possible
  114. # [00:56] <fantasai> Rossen: So add back the 'ascii-digits' value.
  115. # [00:56] <jdaggett> text-combine-horizontal: none | all | digits
  116. # [00:56] <jdaggett> covers 99% of the use cases
  117. # [00:56] <fantasai> Rossen: Let's specify ascii digits only
  118. # [00:56] <fantasai> Rossen: as 'digits'
  119. # [00:56] <fantasai> Rossen: If we want more, then add 'digits-extended' or something.
  120. # [00:56] <fantasai> Rossen: That's the digits value
  121. # [00:57] <fantasai> Rossen: Then the discussion went on to well, we also hate the name it's quite verbose
  122. # [00:57] <fantasai> Rossen: text-combine has some historical bad connotations
  123. # [00:57] <jdaggett> i agree
  124. # [00:57] <fantasai> Rossen: so apparently we should stay away from that
  125. # [00:57] <jdaggett> exactly what Rossen is saying...
  126. # [00:57] <fantasai> Rossen: Our proposal was instead of text-combine-horizontal, just go with text-horizontal
  127. # [00:57] <fantasai> Rossen: When text is horizontal, it has no effect
  128. # [00:57] <fantasai> Rossen: when its vertical, it keeps the text horizontal
  129. # [00:58] <fantasai> dbaron: text-horizontal: none; makes no sense to me
  130. # [00:58] <fantasai> dbaron: Maybe use 'normal', or 'auto', but text-horizontal: none sounds like asking for vertical text....
  131. # [00:59] * TabAtkins_ thinks we should avoid using 'auto' too early in a property's lifecycle.
  132. # [00:59] * fantasai text-horizontal: whatever
  133. # [00:59] <TabAtkins_> glenn: I like the 'combine' in the property name.
  134. # [00:59] <jdaggett> or text-inline?
  135. # [00:59] * sylvaing detects a match for the :bikeshedding state
  136. # [00:59] * stearns why not tate-chuu-yoko? It's got hyphens in the name and everything
  137. # [01:00] * jdaggett oh the peanut gallery is full today
  138. # [01:00] <fantasai> Glenn: 'all' value says that if there's an element boundary between, reverts to none. Why does it prevent combination if I want to color one of the characters?
  139. # [01:00] <fantasai> szilles: That's a separate issue.
  140. # [01:01] <fantasai> fantasai: That was for implementation simplicity.
  141. # [01:01] <fantasai> Rossen: Let's go issue by issue
  142. # [01:01] <fantasai> szilles: If I put a block in, and make it switch direction, then I can do anything I want
  143. # [01:01] <fantasai> szilles: There's another mechanism that allows you to do that.
  144. # [01:01] * jdaggett goes back to reading case folding algorithms
  145. # [01:01] <fantasai> szilles: This is only for one simple thing, therefore well-defiend in simple case.
  146. # [01:01] * sylvaing hey, we could just add a pseudo-element for horizontal bits of text!
  147. # [01:02] * sylvaing ok, that wasn't funny
  148. # [01:02] <fantasai> fantasai: Setting writing-mode: horizontal-tb; would get you an inline block that does whatever you want
  149. # [01:02] <fantasai> szilles: This also compresses whatever you put in there to fit within an em
  150. # [01:02] <SimonSapin> nobody asked for vertical digits in horizontal text?
  151. # [01:02] <fantasai> Glenn: Does it allow overlap of advancement?
  152. # [01:02] <sylvaing> SimonSapin, use-case?
  153. # [01:02] <fantasai> szilles: Believe that's UA-defined
  154. # [01:03] <fantasai> Rossen: Going back to first issue, reintroducing 'digits' value. Does anyone have an objection to that?
  155. # [01:03] <SimonSapin> sylvaing, messing with spec writers
  156. # [01:03] <fantasai> Bert: Why not use a 'display' value?
  157. # [01:03] <fantasai> fantasai: Wouldn't be able to do the automatic processing, which is important.
  158. # [01:04] * sylvaing SimonSapin, that's not a use-case, it's a *goal*. RESOLVED.
  159. # [01:04] <fantasai> http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/#text-combine-horizontal
  160. # [01:04] <fantasai> szilles: Seems like nobody's opposed to adding those values back in, just change the name so that ascii is implied
  161. # [01:04] <fantasai> s/those values/that value/
  162. # [01:04] <fantasai> RESOLVED: Add 'ascii-digits' back in as 'digits' to text-combine-horizontal
  163. # [01:05] <jdaggett> good
  164. # [01:05] <fantasai> Rossen explains what this value does
  165. # [01:05] <fantasai> to Bert
  166. # [01:05] <fantasai> Glenn: Why limit to ASCII digits?
  167. # [01:06] <jdaggett> because that's the use case
  168. # [01:06] <fantasai> Rossen: This is the 90% use case, and it's simple
  169. # [01:06] <jdaggett> arabic digits == no use case!!!!!!!!!!!!!!
  170. # [01:06] <jdaggett> ditto for any other sort of digit you want to find in Unicode
  171. # [01:06] * fantasai thinks roman numeral digits would have a use case in japanese
  172. # [01:06] <jdaggett> actually it's the 99.999999999999999999999999% use case
  173. # [01:07] <fantasai> Glenn wants all Nd characters from Unicode
  174. # [01:07] <jdaggett> ^ bikeshedding
  175. # [01:07] <fantasai> szilles: Don't want all digits b/c definitely don't want fullwidth digits to combine
  176. # [01:07] <jdaggett> Nd characters == no matching use case
  177. # [01:08] <jdaggett> the only real use case outside of digits is
  178. # [01:08] <fantasai> Glenn wants naming the other way around, with 'digits' being generic and a more specific name for the ASCII digits thing.
  179. # [01:08] <jdaggett> 1.3
  180. # [01:08] <jdaggett> but authors can use 'all' for that
  181. # [01:08] <jdaggett> ascii-digits == silly name
  182. # [01:09] <fantasai> szilles: I'm neutral on the name. In the end I don't think it matters.
  183. # [01:09] <fantasai> Glenn: Do we elsewhere use the term digits when we specify that it refers to Unicode definition of digits?
  184. # [01:09] * sylvaing oh yeah, let's argue ASCII/non-ASCII: it's proven to be the best way to resolve things
  185. # [01:09] <jdaggett> the value name is contextual
  186. # [01:09] <jdaggett> in this case digits means ascii digits
  187. # [01:10] <jdaggett> keep it simple please...
  188. # [01:10] <fantasai> fantasai: I think the closest thing we have is font-variant-numeric, which uses -numeric and -nums
  189. # [01:10] <fantasai> koji: CSS Speech has speak-as: digits
  190. # [01:11] <fantasai> szilles: Is digits a technical term in the Unicode spec?
  191. # [01:11] <fantasai> The Nd category is called " Number, Decimal Digit"
  192. # [01:11] * fantasai actually wonders why we use -nums instead of -digits
  193. # [01:12] * jdaggett oh please stop...
  194. # [01:12] * fantasai isn't sure which is correct
  195. # [01:12] * sylvaing Because Unicode and/or OpenType call them numerals, among other things?
  196. # [01:12] * jdaggett is looking for his suicide pills...
  197. # [01:13] * sylvaing John, if you want LC you got to accept some renaming....
  198. # [01:13] * jdaggett yes, that's right, i forgot the rule
  199. # [01:13] * jdaggett when near LC, must debate silly minor name changes...
  200. # [01:13] * sylvaing we enforce all the unwritten rules
  201. # [01:14] <jdaggett> btw, -nums was used partly because we had -caps already
  202. # [01:15] <jdaggett> and this has been debated on www-style before
  203. # [01:15] <fantasai> Glenn concedes on digits
  204. # [01:15] * sylvaing did the scribe just give up and go home?
  205. # [01:15] <fantasai> Bert: Why 'all'?
  206. # [01:16] <fantasai> Rossen: 'digits' implies auto-discovery
  207. # [01:16] <fantasai> Rosen: 'all' implies you've found your content, and you transform it
  208. # [01:16] <jdaggett> because you want to deal with cases like '1.3'
  209. # [01:16] <jdaggett> which there are examples of in existing content
  210. # [01:18] <fantasai> Rossen: So, text-horizontal?
  211. # [01:18] <fantasai> TabAtkins: Kinda like having the 'combine' in the name
  212. # [01:19] <fantasai> fantasai: One problem I have with 'text-combine-horizontal' is that we have 'glyph-orientation-horizontal'
  213. # [01:19] <fantasai> fantasai: The first takes effect only in vertical text, the second takes effect only in horizontal text
  214. # [01:19] <fantasai> also it's long....
  215. # [01:19] <fantasai> Rossen: We can leave this open
  216. # [01:19] <fantasai> Rossen: Call it 'horizontal-in-vertical'
  217. # [01:20] <jdaggett> ewwww
  218. # [01:20] <SimonSapin> yay for 'text-combine'! works for vertical stacks of digits in horizontal text
  219. # [01:20] <fantasai> plinss suggests using the ideographic characters
  220. # [01:20] <fantasai> TabAtkins protests this violates earlier decision not to add non-ASCII property names
  221. # [01:20] <fantasai> fantasai points out it is not bicameral
  222. # [01:21] * jdaggett oh dear, the wg members are hitting the bottle early...
  223. # [01:21] <fantasai> [the jokes get worse and worse]
  224. # [01:21] * sylvaing jdaggett, so it's not just me...
  225. # [01:21] * jdaggett i have my jack at the ready, good for washing down suicide pills...
  226. # [01:22] * sylvaing jdaggett, you're in AZ. I believe they'll provide the gun for free.
  227. # [01:22] <jdaggett> text-縦中横はどう?
  228. # [01:23] <TabAtkins_> jdaggett: +1
  229. # [01:23] * jdaggett ah true, don't they sell those in liquor stores here
  230. # [01:23] <TabAtkins_> jdaggett: Though the question mark shouldn't be part of the proeprty name.
  231. # [01:23] <TabAtkins_> As written, it'll be included in the ident.
  232. # [01:23] * sylvaing probably comes with a 6-pack
  233. # [01:23] <fantasai> fantasai: So we have some open naming issues. Suggest we don't solve any of them right now.
  234. # [01:24] <fantasai> szilles: 'force-horizontal'
  235. # [01:24] * Joins: franremy (~franremy@public.cloak)
  236. # [01:24] <jdaggett> that works too
  237. # [01:24] <fantasai> plinss: Next?
  238. # [01:24] <dbaron> plinss: could also do text-force-horizontal
  239. # [01:24] <dbaron> (but a bunch of people did like force-horizontal)
  240. # [01:25] <jdaggett> or text-inline...
  241. # [01:25] * Quits: tantek (~tantek@public.cloak) (tantek)
  242. # [01:25] <dbaron> Topic: before/after logical directions
  243. # [01:26] <jdaggett> hmmm, logical direction discussions for a spec we want to go to LC?
  244. # [01:26] * Joins: tantek (~tantek@public.cloak)
  245. # [01:26] <fantasai> [above/below is an available pair]
  246. # [01:26] * jdaggett oh, this discussion...
  247. # [01:26] <fantasai> [someone mentions they're kindof oriented up/down, but so are over/under]
  248. # [01:27] <dbaron> There was also a brief joke about using 上/下.
  249. # [01:27] <fantasai> fantasai: at least people are more likely to guess correctly which of above/below start/end is in which direction
  250. # [01:28] <fantasai> szilles: I think it's better to stay with before/after until we come up with clearly better terms, but I admit to being biased.
  251. # [01:29] <fantasai> fantasai: above/below do clearly map to those ideographic characters :)
  252. # [01:29] <fantasai> Topic: CSS2.1
  253. # [01:30] <fantasai> fantasai: Status of errata? Are they in sync with resolutions?
  254. # [01:30] <fantasai> fantasai: How do we get an up-to-date draft somewhere public?
  255. # [01:30] <fantasai> Bert: Make a WD. Or PER?
  256. # [01:31] <fantasai> dbaron: PER is like LC and PR at the same time
  257. # [01:31] <fantasai> dbaron: Get LC comments, and a simultaneous AC vote
  258. # [01:31] <fantasai> Bert: Probably want WD then
  259. # [01:32] <fantasai> fantasai: We're just going to confuse everyone by publishing it as WD
  260. # [01:33] <fantasai> dbaron: Think we should do an Editor's Draft, and at some point go to PER
  261. # [01:33] <fantasai> Bert: That's confusing, having a non-official WD and still want comments on it.
  262. # [01:33] <fantasai> dbaron: It may be that most of the rest of the world doesn't know that PER is like LC
  263. # [01:34] * Quits: liam (liam@public.cloak) (Client closed connection)
  264. # [01:34] * sylvaing wait, there is a stage that is like LC but nothing gets renamed? Can we use that all the time?
  265. # [01:34] <fantasai> Discussing process of updating the 2.1 REC
  266. # [01:35] <fantasai> dbaron: I think we should have a public editor's draft before PER
  267. # [01:35] <fantasai> dbaron: Would rather not go through rest of the process
  268. # [01:35] <fantasai> dbaron: Don't want LC/CR again for example
  269. # [01:35] <fantasai> dbaron: Publishing WD would be a confusing signal
  270. # [01:36] * Joins: franremy2 (~franremy@public.cloak)
  271. # [01:37] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 60 seconds)
  272. # [01:40] <fantasai> [not minuting this]
  273. # [01:40] <fantasai> szilles: Prior draft to PER would be the REC itself
  274. # [01:40] <fantasai> szilles: Only if the PER is rejected would it have to go back to WD.
  275. # [01:41] <fantasai> szilles: Requirements are you describe in the PER what has changed since REC, but errata already do that.
  276. # [01:41] <fantasai> szilles: Fact that we work in public is just a side benefit
  277. # [01:41] <fantasai> szilles: Best I can determine, it's not inventing new process.
  278. # [01:41] <fantasai> Bert: The reason we're publishing an editor's draft is to help people o that they don't have to look at the errata.
  279. # [01:42] <fantasai> Bert: But the editor's draft is not WG-approved. How are we helping?
  280. # [01:42] <fantasai> tantek: transparency
  281. # [01:42] <fantasai> fantasai: You can double check the editor by double-checking the errata
  282. # [01:44] <fantasai> [more process discussion]
  283. # [01:45] <fantasai> szilles: Best plan I've heard so far is that we begin to develop the text for the PER as an open editor's draft, and that when we get it to point where we think we're happy with it, and we have implementation report, we request a PER.
  284. # [01:45] <fantasai> szilles: That means having some way of writing an implementation report.
  285. # [01:46] * Quits: franremy2 (~franremy@public.cloak) (Ping timeout: 60 seconds)
  286. # [01:46] <fantasai> fantasai: That makes sense. /TR is up-to-date because it has errata, editor's draft is up-to-date b/c editor's draft. As long as we keep the errata and the editor's draft in sync, everything's in sync
  287. # [01:47] <fantasai> fantasai: As long as Bert checks things into both places, it's good
  288. # [01:47] <fantasai> RESOLVED: Follow szilles' plan. Bert takes responsibility for keeping things in sync.
  289. # [01:48] <fantasai> Bert: Where do we put the editor's draft?
  290. # [01:48] <fantasai> Bert: Annoyance with Mercurial is that making edits to any module requires merging/updating all others.
  291. # [01:49] <fantasai> [Bert describes annoyances of working with mercurial vs. cvs]
  292. # [01:50] * tantek is relieved he's not the only one who suffers with a lot of friction with our editing / source control tools.
  293. # [01:50] <fantasai> dbaron: You can commit just a directory, rather than all changes to the repo
  294. # [01:50] * tantek observes that he was having a ton of mercurial problems a year ago - as minuted at the Paris meeting.
  295. # [01:51] * jdaggett btw, just pushed a new draft of the css3 fonts spec, with caseless family name matching spelled out:
  296. # [01:51] * jdaggett http://dev.w3.org/csswg/css3-fonts/#font-family-casing
  297. # [01:51] * tantek wonders if all these magic incantation suggestions for using mercurial are documented on the wiki.
  298. # [01:51] * sylvaing tantek, weren't they setup problems on the mac?
  299. # [01:51] <tantek> sylvaing - sure, plenty
  300. # [01:51] <fantasai> Bert: I can't do a push unless everything has been committed
  301. # [01:51] * sylvaing fwiw i couldn't make it work on my mac.
  302. # [01:51] <fantasai> plinss offers to help Bert offline
  303. # [01:52] <fantasai> fantasai: So goal is that it shows up on dev.w3.org and how that happens it TBD
  304. # [01:53] <fantasai> ACTION Bert: publish editor's draft of CSS2.1
  305. # [01:53] * trackbot is creating a new ACTION.
  306. # [01:53] <trackbot> Created ACTION-531 - Publish editor's draft of CSS2.1 [on Bert Bos - due 2013-02-12].
  307. # [01:55] <fantasai> SimonSapin: Changes to syntax, should we backport?
  308. # [01:56] <fantasai> fantasai: If there are changes in behavior, we should keep the two specs in sync
  309. # [01:56] <fantasai> Topic: CSS3 Syntax changes from 2.1
  310. # [01:56] <SimonSapin> http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-tokenizer
  311. # [01:56] <SimonSapin> thttp://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-core-grammar
  312. # [01:56] <SimonSapin> http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-core-grammar
  313. # [01:57] <fantasai> dbaron: I disagree with the change to DASHMATCH and INCLUDES
  314. # [01:57] * Joins: SteveZ (~chatzilla@public.cloak)
  315. # [01:58] <fantasai> dbaron: I want to see ... because that's hard.
  316. # [01:58] <fantasai> SimonSapin: DASHMATCH is important for disambiguation with namespace
  317. # [01:58] <fantasai> dbaron: You need DASHMATCH to avoid two-token lookahead
  318. # [01:58] <fantasai> SimonSapin: I had 3 in my implementation
  319. # [01:58] <fantasai> dbaron: With DASHMATCH, I believe nothing in CSS needs more than 1 token of lookahead
  320. # [01:58] <fantasai> in the parser
  321. # [01:59] <fantasai> dbaron: If you implement attribute matching without DASHMATCH and namespaces, you'll need 2-token lookahead
  322. # [01:59] <fantasai> dbaron: If you're parsing attribute selector and you see |, you can't tell whether namespace or |= without 2-token lookahead
  323. # [02:00] <fantasai> TabAtkins: What are your opinions on other match tokens. Should we just have DASHMATCH?
  324. # [02:00] <fantasai> SimonSapin: Selectors 3 added a few attribute selector operators
  325. # [02:00] <fantasai> SimonSapin: Tokenizer only had tokenizer for a few
  326. # [02:00] <fantasai> dbaron: Thought change was implicit in 3
  327. # [02:00] <fantasai> dbaron: Gecko adds tokens for all the match types in Selectors
  328. # [02:00] <fantasai> TabAtkins: Ok, that seems fine
  329. # [02:01] <fantasai> SimonSapin: The core grammar is written that it has a promise not to change
  330. # [02:01] <fantasai> SimonSapin: But if we're fine with changing sometimes, then ok
  331. # [02:01] <fantasai> TabAtkins: We added scinot, so that's a change
  332. # [02:01] <fantasai> TabAtkins: Agreed to pull plus/minus signs into NUMBER token
  333. # [02:01] <fantasai> dbaron: Wouldn't want to backport plus/minus thing to 2.1...
  334. # [02:02] <fantasai> TabAtkins: OK, revert #1 and add additional tokens for Selectors
  335. # [02:02] <fantasai> TabAtkins: I need to do testing for #2. There's a thread about it
  336. # [02:02] <fantasai> TabAtkins: Only matches WebKit's parsing, which is stupid.
  337. # [02:02] <fantasai> TabAtkins: I made a lot of decisions based on WebKit and only realized afterward that we do stupid things.
  338. # [02:02] <fantasai> dbaron: All other browsers are more internally consistent, and also more consistent with spec
  339. # [02:03] <fantasai> dbaron: We've only changed this 3-4 times in the past 3-4 years :) Trying to find out what our code does this week.
  340. # [02:03] <fantasai> TabAtkins: Afaict, we haven't gotten any compat bugs on it.
  341. # [02:04] <fantasai> TabAtkins: May not be important that we do something different than everyone else
  342. # [02:04] <fantasai> TabAtkins: 3 and 5 were decided by WG
  343. # [02:04] <fantasai> TabAtkins: #4 is irrelevant for CSS, just lets you use the same parser for SVG.
  344. # [02:04] <fantasai> fantasai: The NUMBER thing looks inconsistent across our specs.
  345. # [02:05] <fantasai> TabAtkins: I'll go through all our specs and check that they're consistent once we're ready to publish this.
  346. # [02:05] <fantasai> TabAtkins: On the parser side, changes are more minor.
  347. # [02:06] <fantasai> TabAtkins: Grammar didn't allow certain things before, now show up
  348. # [02:06] <fantasai> [] blocks, () blocks and functions can now contain {} blocks, at-keywords or semicolons
  349. # [02:06] <fantasai> http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-core-grammar
  350. # [02:10] <dbaron> RESOLUTION: add tokens for all the multi-character attribute selector operators to css3-syntax
  351. # [02:11] <fantasai> Discussion of @page parsing
  352. # [02:13] <dbaron> dbaron: the " Selectors can now contain semicolons " should say it's talking about only selectors for style rules and not @page selectors
  353. # [02:14] <dbaron> TabAtkins: no, because Selectors in the terms of the syntax spec is only selectors in style rules; @page selectors in the terms of the syntax spec are an @-rule prelude
  354. # [02:14] <dbaron> dbaron: ah, that's what I don't like about the multi-level stuff in the syntax spec
  355. # [02:14] <dbaron> TabAtkins: you don't have to implement it as multi-level
  356. # [02:14] <dbaron> dbaron: ... until you make a mistake
  357. # [02:15] <dbaron> dbaron: Maybe the term for the thing thing that the parser parses to go where a selector goes shouldn't be "selector"?
  358. # [02:15] <dbaron> TabAtkins: maybe "style rule prelude"?
  359. # [02:18] <dbaron> [discussion about parsing and how to write and specify parsers]
  360. # [02:19] * Quits: glazou (~glazou@public.cloak) ("Page closed")
  361. # [02:19] <dbaron> Bert: now that selectors can contain semicolons and @-keywords... the whole of an @-page rule ... ...
  362. # [02:20] <dbaron> Tab: @-rules are either rule-filled or declaration-filled. Either of them can have @-rules in them, but nothing can contain both declarations and style rules.
  363. # [02:22] <dbaron> I'd like to have some sort of a conclusion about the terminology in css3-syntax.
  364. # [02:22] <dbaron> but it seems like we're gradually closing the meeting
  365. # [02:22] * Quits: smfr (~smfr@public.cloak) (smfr)
  366. # [02:23] * Quits: SimonSapin (~SimonSapin@public.cloak) ("Page closed")
  367. # [02:24] <fantasai> Meeting closed.
  368. # [02:24] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
  369. # [02:24] * Quits: Kazutaka (~Kazutaka@public.cloak) ("Page closed")
  370. # [02:24] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  371. # [02:25] * Quits: tantek (~tantek@public.cloak) (tantek)
  372. # [02:25] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
  373. # [02:27] * plinss is now known as plinss_away
  374. # [02:27] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
  375. # [02:28] * Quits: plinss_ (~plinss@public.cloak) (Ping timeout: 60 seconds)
  376. # [02:29] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 60 seconds)
  377. # [02:36] * Quits: koji (~koji@public.cloak) (Ping timeout: 60 seconds)
  378. # [02:36] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
  379. # [02:38] * heycam is now known as heycam|away
  380. # [03:11] * sylvaing is now known as sylvaing_away
  381. # [03:16] * Joins: tantek (~tantek@public.cloak)
  382. # [03:18] * Joins: tantek_ (~tantek@public.cloak)
  383. # [03:21] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 60 seconds)
  384. # [03:21] * tantek_ is now known as tantek
  385. # [03:21] * sylvaing_away is now known as sylvaing
  386. # [03:36] * heycam|away is now known as heycam
  387. # [03:45] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
  388. # [03:46] * Joins: cabanier (~cabanier@public.cloak)
  389. # [04:36] * sylvaing is now known as sylvaing_away
  390. # [05:01] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
  391. # [05:08] * plinss_away is now known as plinss
  392. # [05:10] * Joins: dbaron (~dbaron@public.cloak)
  393. # [05:11] <dbaron> so, did the pizza dinner group get back before us or after us?
  394. # [05:28] <dbaron> I'm guessing not, but a bunch of us are in the lobby
  395. # [05:35] * Quits: tantek (~tantek@public.cloak) (tantek)
  396. # [05:46] * Joins: lmclister (~lmclister@public.cloak)
  397. # [06:10] * plinss is now known as plinss_away
  398. # [06:19] * Quits: sylvaing_away (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
  399. # [06:20] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
  400. # [06:20] * Quits: paul___irish (~paul___irish@public.cloak) (Ping timeout: 60 seconds)
  401. # [06:20] * Joins: sylvaing_away (~sylvaing@public.cloak)
  402. # [06:20] * Quits: alexmog (~alexmog@public.cloak) (Ping timeout: 60 seconds)
  403. # [06:20] * Joins: lmclister (~lmclister@public.cloak)
  404. # [06:20] * Joins: paul___irish (~paul___irish@public.cloak)
  405. # [06:20] * Joins: alexmog_away (~alexmog@public.cloak)
  406. # [06:20] * sylvaing_away is now known as sylvaing
  407. # [06:21] * alexmog_away is now known as alexmog
  408. # [06:21] * Joins: stearns_ (~anonymous@public.cloak)
  409. # [06:21] * Joins: hober2 (~ted@public.cloak)
  410. # [06:21] * Quits: sawrubh (~uid6719@public.cloak) (Ping timeout: 60 seconds)
  411. # [06:22] * Quits: stearns (~anonymous@public.cloak) (Ping timeout: 60 seconds)
  412. # [06:22] * Quits: slightlyoff (~uid1768@public.cloak) (Ping timeout: 60 seconds)
  413. # [06:22] * stearns_ is now known as stearns
  414. # [06:22] * Quits: hober (~ted@public.cloak) (Ping timeout: 60 seconds)
  415. # [06:49] * Quits: lmclister (~lmclister@public.cloak) ("")
  416. # [06:57] * Joins: lmclister (~lmclister@public.cloak)
  417. # [07:07] * Joins: isherman-book (~Adium@public.cloak)
  418. # [07:20] * Quits: shepazu (schepers@public.cloak)
  419. # [07:20] * Quits: stearns (~anonymous@public.cloak) (Client closed connection)
  420. # [07:20] * Joins: shepazu (schepers@public.cloak)
  421. # [07:21] * Joins: stearns (~anonymous@public.cloak)
  422. # [07:29] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 60 seconds)
  423. # [07:29] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
  424. # [07:30] * Joins: arronei (~arronei@public.cloak)
  425. # [07:33] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
  426. # [07:34] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
  427. # [07:36] * heycam is now known as heycam|away
  428. # [07:52] * Joins: jdaggett (~jdaggett@public.cloak)
  429. # [07:53] * Joins: isherman-book (~Adium@public.cloak)
  430. # [08:14] <fantasai> http://www.w3.org/mid/CAAWBYDACr4H9w2LMY4ys8PAqvyiOL3m5oHO_ytrdPk6=0R+M2g@mail.gmail.com
  431. # [08:14] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
  432. # [08:14] <fantasai> http://www.w3.org/mid/CAAWBYDACr4H9w2LMY4ys8PAqvyiOL3m5oHO_ytrdPk6=0R+M2g@mail.gmail.com
  433. # [08:15] * Quits: hober2 (~ted@public.cloak) (Client closed connection)
  434. # [08:15] * Joins: hober2 (~ted@public.cloak)
  435. # [08:17] * Joins: sawrubh (~uid6719@public.cloak)
  436. # [08:18] * Joins: slightlyoff (~uid1768@public.cloak)
  437. # [08:20] * Joins: SimonSapin (~simon@public.cloak)
  438. # [08:24] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
  439. # [08:30] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
  440. # [08:47] * Joins: nvdbleek (~nvdbleek@public.cloak)
  441. # [08:53] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
  442. # [09:00] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
  443. # [09:01] * Joins: teoli (~teoli@public.cloak)
  444. # [09:16] * Joins: Ms2ger (~Ms2ger@public.cloak)
  445. # [09:48] * Quits: lmclister (~lmclister@public.cloak) ("")
  446. # [09:53] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  447. # [09:53] * Joins: nvdbleek (~nvdbleek@public.cloak)
  448. # [09:53] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  449. # [09:53] * Joins: nvdbleek (~nvdbleek@public.cloak)
  450. # [09:54] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  451. # [09:54] * Joins: nvdbleek (~nvdbleek@public.cloak)
  452. # [09:54] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  453. # [09:55] * Joins: nvdbleek (~nvdbleek@public.cloak)
  454. # [09:55] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  455. # [09:55] * Joins: nvdbleek (~nvdbleek@public.cloak)
  456. # [09:56] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  457. # [09:56] * Joins: nvdbleek (~nvdbleek@public.cloak)
  458. # [09:56] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  459. # [09:56] * Joins: nvdbleek (~nvdbleek@public.cloak)
  460. # [09:57] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  461. # [09:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
  462. # [09:57] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  463. # [09:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
  464. # [09:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  465. # [09:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
  466. # [09:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  467. # [09:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
  468. # [09:59] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  469. # [09:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
  470. # [09:59] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  471. # [09:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
  472. # [10:00] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  473. # [10:00] * Joins: nvdbleek (~nvdbleek@public.cloak)
  474. # [10:00] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  475. # [10:00] * Joins: nvdbleek (~nvdbleek@public.cloak)
  476. # [10:01] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  477. # [10:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
  478. # [10:02] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  479. # [10:02] * Joins: nvdbleek (~nvdbleek@public.cloak)
  480. # [10:02] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  481. # [10:02] * Joins: nvdbleek (~nvdbleek@public.cloak)
  482. # [10:03] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  483. # [10:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
  484. # [10:04] * Joins: franremy (~franremy@public.cloak)
  485. # [10:26] * Quits: arronei (~arronei@public.cloak) (Client closed connection)
  486. # [10:26] * Joins: arronei (~arronei@public.cloak)
  487. # [10:32] * Quits: franremy (~franremy@public.cloak) ("Nettalk6 - www.ntalk.de")
  488. # [10:37] * Joins: jdaggett (~jdaggett@public.cloak)
  489. # [10:39] * sylvaing is now known as sylvaing_away
  490. # [10:58] * Joins: franremy (~franremy@public.cloak)
  491. # [10:59] * Quits: franremy (~franremy@public.cloak) ("Nettalk6 - www.ntalk.de")
  492. # [11:08] * Joins: nvdbleek1 (~nvdbleek@public.cloak)
  493. # [11:08] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
  494. # [11:11] * Quits: slightlyoff (~uid1768@public.cloak) (Ping timeout: 60 seconds)
  495. # [11:13] * Quits: sawrubh (~uid6719@public.cloak) (Ping timeout: 60 seconds)
  496. # [11:29] * Joins: slightlyoff (~uid1768@public.cloak)
  497. # [12:07] * Joins: cabanier (~cabanier@public.cloak)
  498. # [12:30] * Quits: nvdbleek1 (~nvdbleek@public.cloak) ("Leaving.")
  499. # [12:30] * Joins: nvdbleek (~nvdbleek@public.cloak)
  500. # [12:30] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  501. # [12:30] * Joins: nvdbleek (~nvdbleek@public.cloak)
  502. # [12:34] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  503. # [12:34] * Joins: nvdbleek (~nvdbleek@public.cloak)
  504. # [12:37] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  505. # [12:37] * Joins: nvdbleek (~nvdbleek@public.cloak)
  506. # [12:38] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  507. # [12:38] * Joins: nvdbleek (~nvdbleek@public.cloak)
  508. # [12:39] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  509. # [12:39] * Joins: nvdbleek (~nvdbleek@public.cloak)
  510. # [12:41] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  511. # [12:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
  512. # [12:43] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  513. # [12:43] * Joins: nvdbleek (~nvdbleek@public.cloak)
  514. # [12:44] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  515. # [12:44] * Joins: nvdbleek (~nvdbleek@public.cloak)
  516. # [12:47] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  517. # [12:47] * Joins: nvdbleek (~nvdbleek@public.cloak)
  518. # [12:49] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  519. # [12:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
  520. # [12:49] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  521. # [12:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
  522. # [12:50] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
  523. # [12:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  524. # [12:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
  525. # [12:59] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  526. # [12:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
  527. # [12:59] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  528. # [12:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
  529. # [13:01] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  530. # [13:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
  531. # [13:02] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  532. # [13:02] * Joins: nvdbleek (~nvdbleek@public.cloak)
  533. # [13:03] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  534. # [13:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
  535. # [13:04] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  536. # [13:04] * Joins: nvdbleek (~nvdbleek@public.cloak)
  537. # [13:05] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  538. # [13:05] * Joins: nvdbleek (~nvdbleek@public.cloak)
  539. # [13:05] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  540. # [13:05] * Joins: nvdbleek (~nvdbleek@public.cloak)
  541. # [13:06] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  542. # [13:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
  543. # [13:07] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  544. # [13:07] * Joins: nvdbleek (~nvdbleek@public.cloak)
  545. # [13:08] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  546. # [13:08] * Joins: nvdbleek (~nvdbleek@public.cloak)
  547. # [13:09] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  548. # [13:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
  549. # [13:10] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  550. # [13:10] * Joins: nvdbleek (~nvdbleek@public.cloak)
  551. # [13:11] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  552. # [13:11] * Joins: nvdbleek (~nvdbleek@public.cloak)
  553. # [13:13] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  554. # [13:13] * Joins: nvdbleek (~nvdbleek@public.cloak)
  555. # [13:14] * Joins: sawrubh (~uid6719@public.cloak)
  556. # [13:14] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  557. # [13:14] * Joins: nvdbleek (~nvdbleek@public.cloak)
  558. # [13:15] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  559. # [13:15] * Joins: nvdbleek (~nvdbleek@public.cloak)
  560. # [13:16] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  561. # [13:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
  562. # [13:18] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  563. # [13:18] * Joins: nvdbleek (~nvdbleek@public.cloak)
  564. # [13:18] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  565. # [13:18] * Joins: nvdbleek (~nvdbleek@public.cloak)
  566. # [13:19] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  567. # [13:19] * Joins: nvdbleek (~nvdbleek@public.cloak)
  568. # [13:20] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  569. # [13:20] * Joins: nvdbleek (~nvdbleek@public.cloak)
  570. # [13:24] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  571. # [13:24] * Joins: nvdbleek (~nvdbleek@public.cloak)
  572. # [13:25] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  573. # [13:25] * Joins: nvdbleek (~nvdbleek@public.cloak)
  574. # [13:26] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  575. # [13:26] * Joins: nvdbleek (~nvdbleek@public.cloak)
  576. # [13:29] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  577. # [13:29] * Joins: nvdbleek (~nvdbleek@public.cloak)
  578. # [13:29] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  579. # [13:29] * Joins: nvdbleek (~nvdbleek@public.cloak)
  580. # [13:30] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  581. # [13:30] * Joins: nvdbleek (~nvdbleek@public.cloak)
  582. # [13:31] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  583. # [13:31] * Joins: nvdbleek (~nvdbleek@public.cloak)
  584. # [13:34] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  585. # [13:34] * Joins: nvdbleek (~nvdbleek@public.cloak)
  586. # [13:35] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  587. # [13:35] * Joins: nvdbleek (~nvdbleek@public.cloak)
  588. # [13:37] * Joins: nvdbleek1 (~nvdbleek@public.cloak)
  589. # [13:37] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
  590. # [13:40] * Joins: florian (~florian@public.cloak)
  591. # [13:43] * Joins: tmpsantos (~tmpsantos@public.cloak)
  592. # [13:43] * Quits: tmpsantos (~tmpsantos@public.cloak) ("Leaving")
  593. # [13:49] * Quits: nvdbleek1 (~nvdbleek@public.cloak) ("Leaving.")
  594. # [13:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
  595. # [13:49] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  596. # [13:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
  597. # [13:50] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  598. # [13:50] * Joins: nvdbleek (~nvdbleek@public.cloak)
  599. # [14:00] * Quits: florian (~florian@public.cloak) (Client closed connection)
  600. # [14:00] * Joins: florian (~florian@public.cloak)
  601. # [14:04] * Quits: florian (~florian@public.cloak) (Ping timeout: 60 seconds)
  602. # [14:38] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
  603. # [15:05] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
  604. # [15:11] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  605. # [15:17] * Joins: teoli (~teoli@public.cloak)
  606. # [15:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
  607. # [15:56] * Joins: jdaggett (~jdaggett@public.cloak)
  608. # [15:57] * Joins: jdaggett_ (~jdaggett@public.cloak)
  609. # [15:57] * Quits: jdaggett (~jdaggett@public.cloak) (Client closed connection)
  610. # [15:57] * jdaggett_ is now known as jdaggett
  611. # [16:00] * Joins: SimonSapin (~simon@public.cloak)
  612. # [16:05] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
  613. # [16:07] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
  614. # [16:16] * sylvaing_away is now known as sylvaing
  615. # [16:38] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  616. # [16:38] * Joins: nvdbleek (~nvdbleek@public.cloak)
  617. # [16:40] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  618. # [16:40] * Joins: nvdbleek (~nvdbleek@public.cloak)
  619. # [16:41] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  620. # [16:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
  621. # [16:42] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  622. # [16:42] * Joins: nvdbleek (~nvdbleek@public.cloak)
  623. # [16:43] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  624. # [16:43] * Joins: nvdbleek (~nvdbleek@public.cloak)
  625. # [16:45] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  626. # [16:45] * Joins: nvdbleek (~nvdbleek@public.cloak)
  627. # [16:47] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  628. # [16:47] * Joins: nvdbleek (~nvdbleek@public.cloak)
  629. # [16:48] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  630. # [16:48] * Joins: nvdbleek (~nvdbleek@public.cloak)
  631. # [16:49] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  632. # [16:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
  633. # [16:57] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  634. # [16:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
  635. # [16:58] * Joins: glenn (~gadams@public.cloak)
  636. # [16:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  637. # [16:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
  638. # [17:01] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  639. # [17:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
  640. # [17:02] * plinss_away is now known as plinss
  641. # [17:03] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  642. # [17:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
  643. # [17:07] * Joins: Molly (~Molly@public.cloak)
  644. # [17:08] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  645. # [17:08] * Joins: nvdbleek (~nvdbleek@public.cloak)
  646. # [17:09] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  647. # [17:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
  648. # [17:09] * Joins: SimonSapin (~simon@public.cloak)
  649. # [17:10] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
  650. # [17:10] * Joins: SimonSapin1 (~simon@public.cloak)
  651. # [17:10] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  652. # [17:10] * Joins: nvdbleek (~nvdbleek@public.cloak)
  653. # [17:10] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  654. # [17:12] * Joins: jdaggett (~jdaggett@public.cloak)
  655. # [17:12] * jdaggett good morning
  656. # [17:14] * Joins: smfr (~smfr@public.cloak)
  657. # [17:14] <smfr> test
  658. # [17:14] * Joins: dbaron (~dbaron@public.cloak)
  659. # [17:16] * Joins: rhauck (~Adium@public.cloak)
  660. # [17:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
  661. # [17:18] * Joins: glazou (~glazou@public.cloak)
  662. # [17:18] * Joins: mollyholzschlag (~mholzsch@public.cloak)
  663. # [17:22] <glazou> test
  664. # [17:23] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  665. # [17:23] <Ms2ger> test?
  666. # [17:24] <fantasai> They're checking the connection.
  667. # [17:24] * Quits: Molly (~Molly@public.cloak) ("Page closed")
  668. # [17:24] * Joins: koji (~koji@public.cloak)
  669. # [17:24] <glazou> Ms2ger, for display
  670. # [17:28] <fantasai> Topic: Paged Media 4
  671. # [17:28] <glazou> http://www.w3.org/mid/50F29E84.1050804@disruptive-innovations.com
  672. # [17:28] <fantasai> glazou: One of my activities right now is my EPUB editor
  673. # [17:28] <fantasai> glazou: We have a few issues between IDPF and ourselves, W3C
  674. # [17:28] <fantasai> glazou: They are taking things from us that are unstable drafts
  675. # [17:29] <fantasai> glazou: They rely exclusively on XML serialization of HTML5
  676. # [17:29] <fantasai> glazou: One thing ppl do with electronic books is convert Word documents
  677. # [17:29] <fantasai> glazou: Word allows very powerful headers, footers, footnotes, bookmarks, etc.
  678. # [17:29] <fantasai> glazou: GCPM has very weak headers/footers, and all data you can put there comes from generated content
  679. # [17:29] * Joins: rhauck1 (~Adium@public.cloak)
  680. # [17:29] <fantasai> glazou: These are not elements. They're just text.
  681. # [17:30] <fantasai> glazou: Not enough to import document coming from word processor
  682. # [17:30] <fantasai> glazou: We are far behind
  683. # [17:30] <fantasai> glazou: What we do, allow, is not enough to allow ebooks
  684. # [17:30] <fantasai> glazou: And not enough to allow importing Word documents into Web formats, Ebook formats
  685. # [17:30] <fantasai> glazou: The way Håkon designed headers/footers in css3-page
  686. # [17:30] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
  687. # [17:30] <fantasai> glazou: He divides the page margin into 16 boxes
  688. # [17:31] <fantasai> glazou: We have new specs on the radar for csswg, grid, flexbox, regions, etc
  689. # [17:31] <fantasai> glazou: That allow precise layouts
  690. # [17:31] <fantasai> glazou: we don't need so many boxes now
  691. # [17:31] <fantasai> glazou: The idea is to take the parts of GCPM/css3-page that make sense
  692. # [17:31] <fantasai> glazou: And for the rest, deprecate almost what's in Paged Media
  693. # [17:32] <fantasai> glazou: And move towards much more powerful page definitions
  694. # [17:32] * Joins: Kazutaka (~Kazutaka@public.cloak)
  695. # [17:32] <fantasai> glazou: Get flows of content, like what's in the Regions spec, to allow powerful complex headers/footers, which we don't have right now
  696. # [17:32] <fantasai> glazou: If I take first word document from my hard disk, e.g. invoice
  697. # [17:32] <fantasai> glazou: It has header with quote number invoice number, customer number, etc.
  698. # [17:32] <fantasai> glazou: All of that is lost when you import to HTML+CSS
  699. # [17:32] <fantasai> glazou: ebook industry is big enough that we should address this problem
  700. # [17:33] <fantasai> glazou: The current GCPM and css3-page are only implemented by batch processors
  701. # [17:33] <fantasai> glazou: There's not a single browser implementing bits from these specs
  702. # [17:33] <fantasai> glazou: Very basic properties, page size, maybe
  703. # [17:33] <fantasai> glazou: I'd like to hear reasons why they were not implemented
  704. # [17:33] <fantasai> glazou: Not a priority? Only for batch processors? Not implementable? Bad perf?
  705. # [17:33] <fantasai> glazou: My idea is to start Paged Media Level 4
  706. # [17:34] <fantasai> glazou: If you're absolutely not interested, though, it's not worth the time
  707. # [17:34] <fantasai> glazou: Would reuse bits of L3 
  708. # [17:35] <fantasai> tantek: Even if no one is interested, if you have ideas on a simpler proposal, it's worth writing up
  709. # [17:35] <fantasai> tantek: Seeing your ideas may spur other ideas
  710. # [17:35] <stearns> would this be only for printed output, or would it also include paginated views?
  711. # [17:35] <fantasai> glazou: It's not just simplification, but also a harmonization with other proposals in the CSSWG
  712. # [17:35] <fantasai> glazou: In HTML5 we have <header> and <footer> elements. We are not able to deal with them on a per-page basis
  713. # [17:35] <fantasai> dbaron: Wrt priorities, I think the current draft has not been as high priority as other things
  714. # [17:36] <fantasai> dbaron: I think there are many features that look like a lot of work but don't get you much contributes to that, but not the only thing.
  715. # [17:36] <fantasai> glazou: Not asking for commitment to implement or even review, but can I start a draft?
  716. # [17:37] <fantasai> [people seem supportive of this idea]
  717. # [17:38] <fantasai> tantek: One big change that has occurred since GCPM was first developed and framed is,w e shifted from a desktop/print-centric web to a mobile web
  718. # [17:38] <fantasai> tantek: GCPM feels heavyweight large screen
  719. # [17:38] <fantasai> tantek: That's not the focus to day. The focus is mobile
  720. # [17:39] <fantasai> tantek: The only advice I give is any simplification should first, foremost, solve mobile use cases that paged media has rather than books, print, all these edge cases
  721. # [17:39] <fantasai> glazou: Books are an edge case?
  722. # [17:39] <fantasai> szilles: 5% that everybody uses is still pretty important
  723. # [17:39] <fantasai> szilles: displaying info is key role of Web
  724. # [17:39] <stearns> mobile (particularly tablets) should raise the priority of paginated views, imo
  725. # [17:39] <fantasai> szilles: At least one issue with small screens is being able to hvae reasonable pagination
  726. # [17:40] <fantasai> tantek: Do reasonable pagination, but also need to solve the scrolling problem.
  727. # [17:40] <fantasai> glazou: Wrt mobile, one major application is ebook reading
  728. # [17:40] <fantasai> tantek: Yes, mobile ebook reading, but rather than massive complex texts everyone brings as examples
  729. # [17:40] <fantasai> mollyholzschlag: Isn't it included
  730. # [17:40] <fantasai> mollyholzschlag: Our primary role is to have interop across these devcies
  731. # [17:41] <fantasai> mollyholzschlag: I disagree, having many years in publishing industry
  732. # [17:41] <fantasai> mollyholzschlag: Was talking about GCPM to Tim O'Reilly, he said "We are desperate. EPUB does not fulfill the needs we have. We need solution that incorporates the open standards."
  733. # [17:41] <fantasai> Rossen: I wanted to mention, the GCPM spec, the way it is currently standing
  734. # [17:41] <fantasai> Rossen: We've been looking at it quite a bit
  735. # [17:42] <fantasai> Rossen: it's not something which is easy to develop on top of
  736. # [17:42] <fantasai> Rossen: Are we building a platform that other ppl will build on top of?
  737. # [17:42] <fantasai> Rossen: Or are we building the platform which is the reader?
  738. # [17:42] <fantasai> Rossen: GCPM defines a nice reader app, in s
  739. # [17:42] <fantasai> Rossen: If you're building a platform, then implementing GCPM itself does not allow enough programmability for ppl to build on top fo
  740. # [17:42] <fantasai> s/fo/of/
  741. # [17:43] <fantasai> glazou: You are thinking in terms of implementation. I'm thinking in terms of readers and books [?]
  742. # [17:43] <fantasai> glazou: Ebook publishers need to do a lot more with footers and headers
  743. # [17:43] <fantasai> glazou: Not a question of platform, question of usage.
  744. # [17:43] * stearns agrees rabidly with Rossen
  745. # [17:43] <fantasai> Rossen: My point is, e.g. debate of "what is a page". Author should define what is a page.
  746. # [17:44] <fantasai> Rossen: Whatever we do should also be printable
  747. # [17:44] <fantasai> Rossen: All efforst currently putting forward in Fragmentation, regions, etc, are all moving in that direciton of exposing enough primitives on platform so ppl building apps on top can have sufficient resources to do that.
  748. # [17:44] * Joins: lmclister (~lmclister@public.cloak)
  749. # [17:44] <fantasai> glazou: Again, what I have in mind is more harmonization with other specs on WG's radar, than something entirely new
  750. # [17:45] <fantasai> glazou: We have plenty of things, and we don't use them for page definition. We could. It will be much better tailored and much more maintainable and manipulable
  751. # [17:45] * dbaron wants to ask Rossen what he meant by defining what a page is
  752. # [17:45] * Joins: kawabata (~kawabata@public.cloak)
  753. # [17:45] <fantasai> glazou: for Web authors
  754. # [17:45] * fantasai suggests taking that offline
  755. # [17:45] <fantasai> glazou: More controversial... footnotes
  756. # [17:45] <fantasai> glazou: Way theyr'e done in GCPM is way complicated. Should do them with flows.
  757. # [17:45] <fantasai> glazou: Same thing with bookmarks
  758. # [17:46] <fantasai> glazou: A footnote would be an element with some flow
  759. # [17:46] <fantasai> glazou: Has to be tailored, but should be doable.
  760. # [17:46] <fantasai> glazou: Mention the ebook case bcause i'm working on it, but it's not the only one
  761. # [17:46] <fantasai> glazou: When you want to display datay, you want to paginate, to scroll between pages.
  762. # [17:46] <fantasai> glazou: We don't address that.
  763. # [17:46] * Joins: Rossen (~Rossen@public.cloak)
  764. # [17:46] <fantasai> glazou: We are too weak in terms of CSS rendering
  765. # [17:46] <fantasai> glazou: So goal is to try to do that
  766. # [17:46] <fantasai> glazou: My assumption is not that you will agree immediately, but submit ideas to WG and start discussion on that
  767. # [17:47] <fantasai> glazou: Would give very good signal to IDPF if we do that.
  768. # [17:47] <fantasai> RESOLVED: glazou to start css4-page based on ideas outlined above
  769. # [17:47] * Rossen dbaron, my point is that I don't want to define "what a page is", I want to give authors the ability to define it themselves
  770. # [17:47] <fantasai> SimonSapin: I agree with most of what you said, except for the part of deprecating css3-page
  771. # [17:47] * dbaron Rossen, are you talking about allowing authors to do paginated overflow like in Håkon's overflow:paged proposal, or something else?
  772. # [17:48] * SimonSapin1 is now known as SimonSapin
  773. # [17:49] * Rossen dbaron, this is a good start but not sufficient if you want to allow variable page sizes
  774. # [17:49] <SimonSapin> SimonSapin: … because it’s been implemented and used for many years, even though not on the web
  775. # [17:49] * Joins: tantek (~tantek@public.cloak)
  776. # [17:49] <fantasai> Topic: Flexbox
  777. # [17:49] <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012
  778. # [17:49] * dbaron Rossen, that sounds like regions or overflow:fragments
  779. # [17:49] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
  780. # [17:50] <fantasai> First issue is handling of zero-length boxes at end of line
  781. # [17:50] <TabAtkins_> http://dev.w3.org/csswg/css3-flexbox/#algo-line-break
  782. # [17:50] * Rossen dbaron, yes, these proposals are really good start in this direction
  783. # [17:51] * Joins: SteveZ (~chatzilla@public.cloak)
  784. # [17:51] <fantasai> fantasai: Question is what happens if first item is really wide, then add zero-length item
  785. # [17:51] <fantasai> fantasai: Should it stay on first line or go to next line?
  786. # [17:52] <fantasai> [discussion of flex line breaking]
  787. # [17:53] <fantasai> fantasai: We put items until you overflow
  788. # [17:53] <fantasai> TabAtkins: Then back up by one
  789. # [17:53] <fantasai> (unless it's the first item, then don't back up, just break)
  790. # [17:54] <fantasai> TabAtkins: It's possible that you have a negative-length item that will make an overflowing item fit, but we don't look ahead.
  791. # [17:54] <fantasai> szilles: Overflows lefthand side of flexbox?
  792. # [17:54] <fantasai> szilles: What are user expectations?
  793. # [17:55] <fantasai> TabAtkins: Don't use negative margins that big?
  794. # [17:55] <dbaron> sounds like it's worth being clear about what happens with negative margins, and not looking further forward
  795. # [17:55] <fantasai> fantasai: Not a big user expectation issue. Edge cases, we want to make sure implementers are happy with it
  796. # [17:55] * Joins: teoli_ (~teoli@public.cloak)
  797. # [17:56] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
  798. # [17:56] <fantasai> TabAtkins: Suppose flexbox is 300px wide. First 2 items 200px wide, third is -100px
  799. # [17:56] <fantasai> TabAtkins: Theoretically, can fit all three in box
  800. # [17:56] <fantasai> TabAtkins: But since you overflow after adding the second, you break after the first item.
  801. # [17:57] <fantasai> TabAtkins: If ordering was different, had third before second, then all three would fit on first line
  802. # [17:57] <dbaron> dbaron: I'd support defining the negative margins case clearly; it's not defined clearly for inline layout.
  803. # [17:57] <fantasai> fantasai: In the same example, if we had a first item of 400px, and second item is 0px or -100px
  804. # [17:57] <fantasai> fantasai: In both cases, the second item would wrap, even though it doesn't increase the length of the flex line
  805. # [17:58] <fantasai> fantasai: This last example is what this issue is about.
  806. # [17:58] <fantasai> fantasai: Any further comments? People happy with this interpretation of line-breaking?
  807. # [17:59] <fantasai> szilles: Record what Tab said, that use of negative box sizes is discouraged, but it's defined, and in a way that doesn't require excessive lookahead
  808. # [18:00] <fantasai> Issue 2
  809. # [18:00] * trackbot doesn't understand that ISSUE command.
  810. # [18:00] <fantasai> Handling of negative-size flex lines
  811. # [18:00] <dbaron> fantasai: If all items in a flex line have negative cross-size, does the flex line have negative or zero height?
  812. # [18:00] <fantasai> TabAtkins: Decided to clamp the flex line's cross-size at zero
  813. # [18:01] <fantasai> TabAtkins: Could let them be negative, but don't see any reason to do so.
  814. # [18:01] <fantasai> Rossen: wrt regular block flow, where you can do that...
  815. # [18:01] <fantasai> TabAtkins: If you have a wrapper div in block flow, and fill with negative size things, div is still at least zero height
  816. # [18:01] <fantasai> Rossen: [...]
  817. # [18:02] <fantasai> TabAtkins: You can't have negative-height lines, because only way to get negative sizes is negative margins
  818. # [18:02] <fantasai> TabAtkins: In main dimension, can have items overlap each other
  819. # [18:02] <fantasai> TabAtkins: and have them be negative
  820. # [18:03] <fantasai> TabAtkins: In cross direction, can overlap, but not have negative cross-size for lines
  821. # [18:03] <fantasai> szilles: Note that some of these issues are relevant to inline layout
  822. # [18:03] <fantasai> fantasai: This one doesn't apply, because of root inline's line-height.
  823. # [18:05] <fantasai> RESOLVED: Zero-length boxes stay at end of earlier line unless line is already overflowing, in which case they wrap
  824. # [18:05] <fantasai> RESOLVED: flex lines are floored at zero
  825. # [18:05] <fantasai> cross-size
  826. # [18:05] <fantasai> Issue 3
  827. # [18:05] * trackbot doesn't understand that ISSUE command.
  828. # [18:06] <fantasai> fantasai: Wanted to fill flex items, e.g. each item having content with height :100%;
  829. # [18:06] <fantasai> TabAtkins explains Rudolph's case
  830. # [18:06] * Joins: leif (~lstorset@public.cloak)
  831. # [18:06] <fantasai> TabAtkins: No way to fill it without invoking more flexbox
  832. # [18:06] <fantasai> TabAtkins: Believe our proposal is do nothing, it's currently workaroundable
  833. # [18:07] <fantasai> fantasai: But no way to do, e.g. 50% fill
  834. # [18:08] <fantasai> fantasai: Btw, what are percentage margins relative to on a flex item?
  835. # [18:08] <fantasai> TabAtkins: Think it's same as block
  836. # [18:09] <fantasai> fantasai: So relative to containing block's width for both horizontal and vertical margins?
  837. # [18:09] <fantasai> Bert: Should it be relative to writing mode or flex direction?
  838. # [18:09] <fantasai> TabAtkins: If you think of flex as better block, then should be consistent.
  839. # [18:10] <fantasai> Rossen: If your cross size changes, you have margins in percent, that resolves from the main size, by increasing your cross size, main size will increase.
  840. # [18:11] <fantasai> fantasai: Guess this a separate issue, should probably double-check that things work sensibly.
  841. # [18:11] <fantasai> ACTION fantasai: investigate handling of percentage margins on flex items
  842. # [18:11] * trackbot is creating a new ACTION.
  843. # [18:11] <trackbot> Created ACTION-532 - Investigate handling of percentage margins on flex items [on Elika Etemad - due 2013-02-12].
  844. # [18:11] <fantasai> [discussion between Rossen and Tab wrt margins]
  845. # [18:12] <fantasai> Tab, Rossen, and fantasai to investigate during the break
  846. # [18:12] <fantasai> fantasai: So back to the issue, a related concept is that if you have 'stretch' item, it does not propagate definiteness from the flex container to the flex item, so you can't resolve percentages against it.
  847. # [18:13] <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012
  848. # [18:13] <fantasai> fantasai: In Rudolph's case, it's trying to reference an auto size, so percentages definitely wouldn't work.
  849. # [18:14] <fantasai> fantasai: But suppose flex container is definite size, 'stretch' doesn't allow to resolve against that height right now
  850. # [18:14] <fantasai> Rossen: Should do so, because stretch is equivalent to height 100%
  851. # [18:14] <fantasai> Rossen: We did the same thing for Grid as well
  852. # [18:14] <fantasai> ACTION TabAtkins: Make stretch definite when flexbox is single-line
  853. # [18:14] * trackbot is creating a new ACTION.
  854. # [18:14] <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
  855. # [18:14] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
  856. # [18:15] <fantasai> 4th issue, Constant spacing around items
  857. # [18:15] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0249.html
  858. # [18:15] <fantasai> TabAtkins: Basically requesting more spacing controls
  859. # [18:16] <fantasai> TabAtkins: Have had similar requests from yehuda Katz
  860. # [18:16] <fantasai> TabAtkins: Wanting to put fixed spacing among items
  861. # [18:16] <fantasai> TabAtkins: This one wants specific spacing between flex lines, perferably same as spacing between flex items on same line
  862. # [18:16] <fantasai> TabAtkins: Think to defer to Level 2. Want more spacing controls, but do a proper treatment of it later.
  863. # [18:17] <fantasai> RESOLVED: Defer additional spacing controls to Level 2
  864. # [18:17] <fantasai> 5th issue: http://lists.w3.org/Archives/Public/www-style/2012Oct/0220.html
  865. # [18:18] <fantasai> fantasai: If you have percentage that can't be resolved, CSS2.1 says it's treated as auto. Currently spec says it computs to auto, but we decided it's actually the used value that's auto
  866. # [18:18] <fantasai> fantasai: We need that to be clear for this issue to be clear in Flexbox
  867. # [18:18] <fantasai> TabAtkins: Stretch checks against computed value of 'auto'
  868. # [18:19] <fantasai> fantasai: So question is, when does 2.1 erratum get published?
  869. # [18:20] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0437.html
  870. # [18:21] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0466.html
  871. # [18:21] <fantasai> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392
  872. # [18:22] <fantasai> Bert: Did we want to keep the computed value as a percentage so you can back-resolve the parent's width?
  873. # [18:22] <fantasai> fantasai: No idea. Just know that the current text is wrong.
  874. # [18:23] <fantasai> fantasai: Bert, do you need anything from the WG on this issue?
  875. # [18:25] <fantasai> ACTION Bert: Update errata, CSS2.1 spec for bug 15392
  876. # [18:25] * trackbot is creating a new ACTION.
  877. # [18:25] <trackbot> Created ACTION-533 - Update errata, CSS2.1 spec for bug 15392 [on Bert Bos - due 2013-02-12].
  878. # [18:25] <fantasai> Issue 6 was editorial
  879. # [18:25] * trackbot doesn't understand that ISSUE command.
  880. # [18:26] <fantasai> 7th issue was straigthforward, fixing conflicting wording in spec
  881. # [18:26] <fantasai> 8th issue we discussed in December, was waiting on Rossen to confirm
  882. # [18:26] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
  883. # [18:26] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0040.html
  884. # [18:26] <fantasai> Rossen: We ignore aspect ratio once main size is determined
  885. # [18:26] <fantasai> Rossen: Have overlapping content?
  886. # [18:27] <fantasai> TabAtkins: No, no overlapping. Just ignore aspect ratio
  887. # [18:28] <fantasai> Rossen draws example
  888. # [18:29] <fantasai> <div flex><img/><img flex:1/></div>
  889. # [18:29] <fantasai> div is 300px, images 100px each, square
  890. # [18:30] <fantasai> div is 200px tall
  891. # [18:30] <fantasai> TabAtkins: If it's single line, they both stretch to 200px, and main size increases to 200px accordingly
  892. # [18:31] <fantasai> TabAtkins: Then second one is flex: 1, so it negative-flexes to fit, becoming 100px wide. Stays 200px tall.
  893. # [18:35] <fantasai> RESOLVED: Proposed handling of stretched items with intrinsic aspect ratio is accepted.
  894. # [18:36] <fantasai> 9th issue
  895. # [18:37] <fantasai> RESOLVED: http://lists.w3.org/Archives/Public/www-style/2012Dec/0041.html
  896. # [18:37] <fantasai> 10th issue
  897. # [18:38] <fantasai> Do flex items with negative margins increas available space?
  898. # [18:38] <fantasai> fantasai: Flex items can have negative sizes, we don't clamp the outer size to zero
  899. # [18:39] <fantasai> RESOLVED: Flex items can have negative outer size; no clamping to zero
  900. # [18:40] * dbaron notes the midm
  901. # [18:40] * dbaron notes the midmorning croissant arrival
  902. # [18:41] <fantasai> 12th issue: Orthogonal Flex Layouts Sub-optimally Defined
  903. # [18:41] <fantasai> fantasai: We haven't figured out how to solve this yet, so still open
  904. # [18:42] <fantasai> 13th issue: Should ::first-line/::first-letter apply to a flex container?
  905. # [18:42] <fantasai> fantasai: Mailing list seemed to think, why bother at this point, nobody seems to be demanding it and it's additional complexity
  906. # [18:42] <fantasai> TabAtkins: It wouldn't be too tricky, since you'd be propagating into the first flex item.
  907. # [18:42] * Joins: rhauck (~Adium@public.cloak)
  908. # [18:43] <fantasai> RESOLVED: ::first-line/::first-letter don't apply to flex containers. Could revisit later if this is in high demand.
  909. # [18:44] <fantasai> 14th issue was closed as invalid
  910. # [18:44] <fantasai> 15th issue: Should 'overflow' apply to flex containers?
  911. # [18:44] <fantasai> TabAtkins: We answered yes
  912. # [18:45] <fantasai> dbaron: It's a lot of work
  913. # [18:45] <fantasai> TabAtkins: Two of us already do it
  914. # [18:45] <fantasai> dbaron: Is the idea that you run the entire flex layout algorithm as if the container is that size
  915. # [18:45] <fantasai> TabAtkins: And if you overflow, you add scrollbars and do it again
  916. # [18:46] <fantasai> dbaron: If you have horizontal overflow, you make a scrollbar that can go out to there, but then you do the layout as though the width is still the original width minus the scrollbar.
  917. # [18:46] <fantasai> dbaron: Is that clear?
  918. # [18:46] <fantasai> fantasai: I think that's implied in the way overflow is defined
  919. # [18:47] <fantasai> RESOLVED: overflow applies to flex containers
  920. # [18:47] <fantasai> <br type="tea">
  921. # [18:49] * Quits: leif (~lstorset@public.cloak) ("Leaving.")
  922. # [18:55] * plinss is now known as plinss_away
  923. # [18:58] * plinss_away is now known as plinss
  924. # [18:58] * sylvaing is now known as sylvaing_away
  925. # [19:05] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
  926. # [19:13] <fantasai> Topic: Transitions
  927. # [19:13] <fantasai> dbaron: Follow-up from yesterday
  928. # [19:13] <fantasai> dbaron: We agreed on a whole bunch of edits
  929. # [19:13] <fantasai> dbaron: Want to publish a WD with those edits, most of which but not all of which are done,
  930. # [19:13] * Joins: SimonSapin (~simon@public.cloak)
  931. # [19:13] <fantasai> RESOLVED: Publish updated WD of Transitions with those edits
  932. # [19:14] * hober2 is now known as hober
  933. # [19:14] <fantasai> ACTION dbaron: edit publish Transitions
  934. # [19:14] * trackbot is creating a new ACTION.
  935. # [19:14] <trackbot> Created ACTION-534 - Edit publish Transitions [on David Baron - due 2013-02-12].
  936. # [19:14] <fantasai> dbaron: Things are done, except bits wrt moving to other specs
  937. # [19:15] <fantasai> dbaron: In general, should I write them and check them in, or send mail to editors with patches
  938. # [19:15] <fantasai> jdaggett: I want a patch
  939. # [19:15] <fantasai> TabAtkins, fantasai: Just check them in
  940. # [19:15] <fantasai> fantasai: Any editor's other than jdaggett want a patch?
  941. # [19:15] <fantasai> szilles: Which specs affected?
  942. # [19:16] <fantasai> dbaron: High priority are fonts, ui, backgrounds, ...
  943. # [19:16] <fantasai> dbaron: Other thing is, I've made some slight editorial changes
  944. # [19:16] <fantasai> dbaron: table that describes how properties are animatable now looks the way I want animatable lines work
  945. # [19:17] <fantasai> TabAtkins: Can't do just "Animatable: yes" for simple things?
  946. # [19:17] <fantasai> dbaron: Right
  947. # [19:17] <fantasai> TabAtkins: :(
  948. # [19:19] <fantasai> Topic: Cascade of Animations and Transitions
  949. # [19:20] <fantasai> smfr: In august F2F there was a resolution that Transitions happen last in the Cascade
  950. # [19:20] <fantasai> smfr: This related to !important rules overriding animations
  951. # [19:20] <fantasai> dbaron: We did want !important rules to override animations, which meant animations not at the top
  952. # [19:21] <fantasai> dbaron: Also how transitions start as a function of computed style changes, requires them to be on top of everything else that affects computed style
  953. # [19:21] <fantasai> dino: In my mind I agree that !important rules should override animations
  954. # [19:21] <smfr> link to previous discussion: (see 16:42): http://logs.csswg.org/irc.w3.org/css/?date=2012-08-15
  955. # [19:22] <fantasai> dino: [something about stopping animations]
  956. # [19:22] <fantasai> dbaron: But that would stop all animations.
  957. # [19:22] <smfr> dino suggesting that the way to stop animations is animation-name: none !important;
  958. # [19:22] <fantasai> dbaron: If a user needs high contrast colors, but motion is fine, if they try to enforce high contrast they lose animations
  959. # [19:22] <fantasai> dino: Right.
  960. # [19:22] <fantasai> dino: Inconsistency that we discussed a few months ago
  961. # [19:23] <fantasai> dino: Would be nice to set it up so that force color overriding animation
  962. # [19:23] <fantasai> dino: Seems like we need some new special rule for cascade so you can do both what you want and in general case override transitions
  963. # [19:23] <fantasai> dino: red to blue animation infinitely
  964. # [19:24] <fantasai> dino: some other rule applies temporarily trigger a transition that overrides the animation
  965. # [19:24] <fantasai> dino: So supose you have red to blue animation
  966. # [19:24] <fantasai> dino: Have a transition rule on color, color transitions over 1s
  967. # [19:24] <fantasai> dino: :hover rule changes color to green, but it's not !important
  968. # [19:24] <fantasai> dino: It would change the color to green
  969. # [19:24] <fantasai> dino: which interrupts the anmation
  970. # [19:25] <fantasai> dbaron: It would only interrupt if the color to green is a change that overrides the animation
  971. # [19:25] <fantasai> dino: Transitions apply last
  972. # [19:25] <fantasai> dino: Yes, but transition only happens if there's a computed value change to trigger it
  973. # [19:25] <fantasai> dbaron: So, in our model, when we're deciding when to start transitions
  974. # [19:25] <fantasai> dbaron: We're looking at a computed style that already has animation results
  975. # [19:26] <fantasai> dino: So technically would start a transition very often
  976. # [19:26] <fantasai> dbaron getting confused now
  977. # [19:26] <fantasai> dbaron: I know we don't start transitions as a result of changes from animations
  978. # [19:26] <fantasai> dbaron: We have a concept of style with/without animations
  979. # [19:27] <fantasai> smfr: You would only show a transition when there would be a visible change that isn't caused by the animation
  980. # [19:27] <fantasai> smfr: So if !important rule makes it yellow, you start a transition
  981. # [19:27] <fantasai> smfr: What's your starting color?
  982. # [19:28] <fantasai> dbaron: Think it's the currently animating color
  983. # [19:28] <fantasai> fantasai: Think that's what it should be
  984. # [19:28] <fantasai> smfr: More pragmatic point is, WebKit we don't do that. Animations are applied last, overriding !important rules
  985. # [19:28] <fantasai> smfr: So for next year or two we'll have different implementations
  986. # [19:28] <fantasai> smfr: How do we deal with that?
  987. # [19:28] <fantasai> dbaron: From security perspective, bunch of !important rules in our UA style sheet, and they must take effect.
  988. # [19:29] <dbaron> fantasai: I think honoring the !important rules is the right thing for the user.
  989. # [19:31] * hober can no longer hear; tab, are you doing something near the mic?
  990. # [19:31] <fantasai> [lots of discussion that wasn't minuted]
  991. # [19:31] * dino - meeting room has cut out since sylvaing joined skype
  992. # [19:32] <fantasai> szilles: Seems like 2 issues here: whether !important should win, and whether transitions or animations win
  993. # [19:32] <fantasai> fantasai^: [...stuff...]
  994. # [19:33] <fantasai> [mostly about how there seems to be no new info, and we're just repeating the discussion we had last time]
  995. # [19:33] <hober> Present+ hober (remote)
  996. # [19:33] * Joins: sylvaing (~sylvaing@public.cloak)
  997. # [19:33] <fantasai> [which fantasai does not want to minute again, personally\
  998. # [19:34] <fantasai> mollyholzschlag: Wrt a11y and user, animations and transitions are 2 aspects of CSS where a11y does come into play, and having !important, don't have an opinion on transitions vs. animations, but should not interrupt pattern of allowing users !important over that stuff
  999. # [19:34] <fantasai> szilles: If I'm doing an animation, what does it mean for the !important rule to take effect but not stop the animations
  1000. # [19:35] <fantasai> fantasai: It means the animation continues, but that value does not change.
  1001. # [19:35] <fantasai> plinss: Wrt transitions, it's a red herring. If !important rule overrides, and there's a transition to that state, shoudln't affect whether or not !important overrides the statement.
  1002. # [19:35] <fantasai> smfr: In WebKit in theory we would like !important to override, but it's an implementation
  1003. # [19:35] <fantasai> plinss: Nobody's disagreeing
  1004. # [19:35] <fantasai> dino: Maybe explain the point again from last time
  1005. # [19:36] <fantasai> dino: Completely agree that !important style rule should oerride an animation
  1006. # [19:36] <fantasai> dino: But don't think transitions should apply after animations, think it causes inconsistency in the model
  1007. # [19:36] <fantasai> dbaron: Could imagine a model where cascade for animations sort of operates instead of on the actual value on a dummy value that says "the value of this comes from this animation"
  1008. # [19:36] <fantasai> dbaron: And then if that wins in the cascade, then you use the animation
  1009. # [19:36] <fantasai> dbaron: In that sort of model, can see animation overriding the transitions
  1010. # [19:37] <fantasai> dbaron: I know how to do it in our implementation, don't know how to specify it in CSS specs
  1011. # [19:37] <fantasai> TabAtkins doesn't understnad what was just said; fantasai either
  1012. # [19:37] <fantasai> fantasai: Isn't that what transitions is already doing?
  1013. # [19:37] <fantasai> fantasai: I don't understand this assertion that transitions should lose to animations.
  1014. # [19:38] <fantasai> dbaron: If you've specified an animation, that should win over transition between static value
  1015. # [19:38] <fantasai> fantasai: Suppose you have two states, State A and State B.
  1016. # [19:38] <fantasai> fantasai: In State A, you are running animation Q
  1017. # [19:39] <fantasai> fantasai: And in State B, animation Q does not run
  1018. # [19:39] <fantasai> fantasai: Why would you not want a smooth transition from State A to whatever State B wants
  1019. # [19:39] <fantasai> ?
  1020. # [19:40] <fantasai> dbaron: Do you want a transition from the animated state of A, or the non-animated state of A.
  1021. # [19:40] <fantasai> fantasai: whatever I'm seeing at that moment
  1022. # [19:41] <TabAtkins_> .foo { color: yellow; animation: go-from-red-to-blue 1s infinite; }
  1023. # [19:41] <dino> now change color to green
  1024. # [19:41] <TabAtkins_> .foo:hover { color: green; }
  1025. # [19:41] * Quits: shepazu (schepers@public.cloak) (Client closed connection)
  1026. # [19:41] <dino> in both cases you see animation
  1027. # [19:41] * Joins: shepazu (schepers@public.cloak)
  1028. # [19:41] <TabAtkins_> .foo { transition: color 1s; }
  1029. # [19:41] <fantasai> plinss: Nothing triggers a transition, because nothing changes
  1030. # [19:42] <fantasai> plinss: The animation is still overriding the color
  1031. # [19:42] <fantasai> plinss: The color of the element has not change.
  1032. # [19:42] <fantasai> dino: If there was a transition on color, why would we see the yellow-to-green transition?
  1033. # [19:42] <fantasai> s/see/expect/
  1034. # [19:42] <fantasai> plinss, fantasai: Nobody expects that
  1035. # [19:43] <fantasai> dbaron: I think we're going around in circles, yet I don't think there is any disagreement over the desired results
  1036. # [19:44] <fantasai> fantasai: So, suppose in the :hover state, we say animation: none; so that it is in fact green
  1037. # [19:44] <dbaron> I think we agree that (a) we want !important rules to override animations and (b) we want animations to override transitions
  1038. # [19:44] <fantasai> fantasai: Dean is asserting that you won't see the transition, it just snaps to green
  1039. # [19:44] <fantasai> fantasai: And peter and I are saying it should transition to green from whatever color it was starting at.
  1040. # [19:45] <fantasai> dbaron: I don't care what happens in that case, should be whatever's easiest that gets us a nad b
  1041. # [19:46] <fantasai> discussion of where to start
  1042. # [19:46] <fantasai> dbaron: Are you starting from base state of the animation state, the current state of the animation, or the dynamic state of the animation
  1043. # [19:46] <fantasai> plinss and fantasai are sayng the 2nd option
  1044. # [19:47] <fantasai> plinss: When you trigger :hover, the animation has ended
  1045. # [19:47] <fantasai> plinss: you take the state of the animation at that point, and then take that s the starting point and go from there to the :hover state
  1046. # [19:49] <fantasai> dbaron: I think use cases for these features are mostly orthogonal, and interaction should be what makes sense
  1047. # [19:49] <fantasai> dbaron: Four options
  1048. # [19:49] <sylvaing> +1 to david's orthogonality point. the demand to solve this is 100% spec completeness afaik.
  1049. # [19:50] <TabAtkins_> Which is half of why we do anything in this group anyway.
  1050. # [19:51] <sylvaing> ...and it's the half we bikeshed the most on....
  1051. # [19:51] <fantasai> dbaron: Suppose you have p { margin-top: 50px; animation: bounce; }
  1052. # [19:51] <fantasai> @keyframes bounce { from: 100px; to: 150px; }
  1053. # [19:51] <sylvaing> to the risk of being outrageous i'd even propose to keep this undefined in this level.
  1054. # [19:52] <fantasai> s/bounce/bounce alternate/
  1055. # [19:52] <glazou> sylvaing, I'll say it for you
  1056. # [19:52] <fantasai> p { transition: margin-top 2s; }
  1057. # [19:52] <fantasai> p:hover { margin-top: 0; }
  1058. # [19:53] <fantasai> s/bounce/bounce 1s infinite/
  1059. # [19:53] <sylvaing> glazou, thanks. definitely no objection to giving this a shot.
  1060. # [19:53] <fantasai> dbaron draws a graph
  1061. # [19:53] <fantasai> 150px 100px 50px 0px along y axis
  1062. # [19:53] <fantasai> x axis represents time
  1063. # [19:54] <fantasai> hover is halfway along time
  1064. # [19:54] <fantasai> dbaron draws the base-state of the margin at 50px straight through to :hover
  1065. # [19:55] <fantasai> dbaron draws the animated state as a zig zzag from 1000px to 150px sloping up, down, up, then halfway down before hitting hover
  1066. # [19:55] <fantasai> s/1000/100
  1067. # [19:55] <fantasai> :hover { animation: none; }
  1068. # [19:55] <fantasai> plinss: Does anyone disagree that without the animation: none rule, it would just continue to animate?
  1069. # [19:56] <fantasai> Everyone agrees that continuing to animate is what we want
  1070. # [19:56] <fantasai> dbaron draws a dotted line representing this continuation
  1071. # [19:57] <fantasai> dbaron draws 4 options
  1072. # [19:57] <fantasai> 1. If from or to value comes from animation, there's no transition. Just instant change.
  1073. # [19:57] <fantasai> (draws line dropping at hover to zero
  1074. # [19:57] <fantasai> )
  1075. # [19:58] <fantasai> 2. The transition ignores the animation completely. You transition from base state (50px) to zero.
  1076. # [19:58] * sylvaing can't wait to see that pic; cam is a bit fuzzy at that distance
  1077. # [19:58] <fantasai> (draws line dropping from 50px at hover to zero after 2s)
  1078. # [19:59] <glazou> http://lockerz.com/s/281620122
  1079. # [19:59] <fantasai> 3. Take from where the animation left off to where the :hover state is
  1080. # [19:59] <fantasai> (draws line from partway through the zag at :hover down to zero at 2s
  1081. # [19:59] <fantasai> )
  1082. # [20:00] <fantasai> 4. Transition, interpolating between the dynamic state of the animation and zero
  1083. # [20:00] <fantasai> (draws line that zigzags sligtly from the :hover point on the animation to zero)
  1084. # [20:01] <dino> I would be quite scared if we couldn't come to agreement on this situation. It's the !important one that's tricky.
  1085. # [20:01] <fantasai> plinss: 4 should never happen, because the animation is no longer running
  1086. # [20:01] <fantasai> dino: Alternate end state, p:hover { margin-top: 0 !important; }
  1087. # [20:02] <fantasai> s/dino/dbaron/
  1088. # [20:02] <fantasai> dbaron: We have zero models that explains all the other stuff we want, so let's figure out a model that gets us everythign else we want and then see what falls out of that
  1089. # [20:02] <fantasai> plinss: Just before you hovered, there was no animation, but a transition running from some previous state
  1090. # [20:02] <fantasai> suppose
  1091. # [20:03] <fantasai> plinss: Suppose there was no animation, base state is margin-top 50, but just before that you were in some other state, and there's a transition running from that state to the 50px
  1092. # [20:03] <fantasai> plinss: Now you start the :hover.
  1093. # [20:03] <fantasai> plinss: Where are you transitioning from?
  1094. # [20:03] <fantasai> dbaron: That's the open issue Tab has an action item to write a JS simulation for
  1095. # [20:03] * sylvaing must say this is a pretty awesome graph
  1096. # [20:04] <fantasai> plinss: Think the answer to that should inform the answer to this
  1097. # [20:04] * fantasai pokes tantek, can you help sylvaing
  1098. # [20:04] <fantasai> ...
  1099. # [20:04] <fantasai> dbaron: A change caused by an animation does not trigger a transition
  1100. # [20:05] <fantasai> dbaron: Not difficult to go from there to, if your before/after state is an animation, you don't transition
  1101. # [20:05] * sylvaing fantasai, what?
  1102. # [20:05] <fantasai> plinss: It's *an* answer
  1103. # [20:05] <fantasai> plinss: 2 and 3 both make sense
  1104. # [20:05] <dino> I like what I think dbaron is suggesting. (obviously assumes I think what I'm thinking!)
  1105. # [20:05] <fantasai> fantasai: I don't like 2, it jumps
  1106. # [20:06] <fantasai> smfr: 3 is problematic, because, imagine flip this around
  1107. # [20:06] <tantek> fantasai - I think sylvaing has already seen http://pics.lockerz.com/s/281620122
  1108. # [20:06] <sylvaing> what happens with #3 when you un-hover?
  1109. # [20:06] <fantasai> smfr: You're trying to hit a moving target
  1110. # [20:07] <fantasai> plinss: If your :hover is applying a different animation, you're trying to hit two moving targets
  1111. # [20:08] <sylvaing> suspects answers that mitigate jarring visual discontinuities are better for authors but you end up managing 2 or more states for the same computed value which is....weird.
  1112. # [20:08] <fantasai> fantasai: I think in the case smfr outlines, you'd look 2s into the animation, where am I supposed to be, then transition into that.
  1113. # [20:08] <fantasai> fantasai: That's what's going to get you the smooth transition, which is what you want. Otherwise it's jumpy
  1114. # [20:08] <fantasai> dbaron: If you go from big animation to small animation, you can't pick the time that will look right
  1115. # [20:09] <fantasai> dbaron: Because the correct time will depend on the speed you want, which can vary depending on the distance you're trying to hit
  1116. # [20:09] <fantasai> smfr: We don't have paced animations
  1117. # [20:09] <fantasai> [discussion of velocity]
  1118. # [20:10] <sylvaing> if an author wants something this sophisticated, i'm not sure the current level of Transitions/Animations cuts it.
  1119. # [20:10] <fantasai> dbaron: Then you need distance functions for all your properties.
  1120. # [20:10] <fantasai> plinss: That's a level 4 Transitions feature
  1121. # [20:10] <fantasai> dbaron: Level 5
  1122. # [20:10] <sylvaing> Web Animations Level 6!
  1123. # [20:10] <fantasai> plinss: Yeah. But I think it's an important use case that we should get to
  1124. # [20:10] <fantasai> ...
  1125. # [20:11] <fantasai> plinss: The only way you'd get behavior of 4 is if the animation continues during the transition period even though you've turned it off. It could be rational, but you turned it off
  1126. # [20:11] <fantasai> s/you turned it off/a lot of work/
  1127. # [20:11] <sylvaing> agree #4 isn't an option in this case.
  1128. # [20:12] <dbaron> The example markup ended up being:
  1129. # [20:12] <fantasai> smfr: Have a few high-level comments.
  1130. # [20:12] <dbaron> p { margin-top: 50px; transition: margin-top 2s linear; animation: bounce 1s infinite alternate }
  1131. # [20:12] <fantasai> smfr: Think looking at use cases and desired behavior is good, for coming up with correct model
  1132. # [20:12] <sylvaing> +1 to smfr
  1133. # [20:12] <dbaron> @keyframes bounce { from { margin-top: 100px } to { margin-top: 150px } }
  1134. # [20:12] <fantasai> smfr: Also for current level of spec, not sure we'll come to agreement.
  1135. # [20:12] <fantasai> smfr: Agree with sylvaing, maybe we should leave this undefined.
  1136. # [20:12] <dbaron> [option 1] p:hover { margin-top: 0; animation: none }
  1137. # [20:12] <dbaron> [option 2] p:hover { margin-top: 0 ! important }
  1138. # [20:13] <fantasai> szilles: Problem with that is you can't fix it if there's wide deployment of something
  1139. # [20:13] <sylvaing> szilles, I think that's a feature...
  1140. # [20:13] <fantasai> fantasai: What exactly are we proposing to undefine?
  1141. # [20:13] <fantasai> dbaron: I think we need to work on a model that answers the rest of the stuff
  1142. # [20:13] <fantasai> dbaron: How we describe how transitions/animations interat with cascade, even ignoring this issue.
  1143. # [20:14] <fantasai> dbaron: How do transitions interact with cascade, how do animations interact with cascade, ignoring how they interact with each other
  1144. # [20:14] <fantasai> dbaron: Maybe including how they interact with each other in the non-boundary case.
  1145. # [20:14] <fantasai> fantasai: You mean, if we remove 'animation: none' from that example
  1146. # [20:15] <dbaron> (i.e., with [option 3] p:hover { margin-top: 0 })
  1147. # [20:15] <fantasai> fantasai: Since we agree the animation should just keep going
  1148. # [20:15] <fantasai> szilles: If an animation is running and therefore defining the value of a property, then using some other mechanism to change the value of that property has no effect (regardless of whether a transition period was defined)
  1149. # [20:15] <fantasai> szilles: The animation is overriding the value of the property anyway
  1150. # [20:16] <fantasai> szilles: question is interesting, if the animation stops, completes, then what's the value of the property?
  1151. # [20:16] <dbaron> we all agree that p { margin-top: 50px; transition: margin-top 2s; animation: bounce 1s infinite alternate } @keyframes bounce { from { margin-top: 100px } to { margin-top: 150px } } p:hover { margin-top: 0 } should produce no visible transition (the animation should just keep going)
  1152. # [20:16] <fantasai> szilles: :hover is still there, animation completes
  1153. # [20:16] <fantasai> plinss: When the animation completes, return to the base value of the property
  1154. # [20:16] * Joins: cabanier (~cabanier@public.cloak)
  1155. # [20:16] <sylvaing> once animation completes i'd expect the :hover rule to apply
  1156. # [20:16] <fantasai> right
  1157. # [20:17] <fantasai> szilles: If you're in :hover, and animation terminates while you're in :hover, whatever cascade says value will be will be the value
  1158. # [20:17] * fantasai thinks sylvaing just said that more clearly
  1159. # [20:17] <fantasai> szilles: Question then is, is a transition triggered when the animation stops?
  1160. # [20:18] <fantasai> smfr: Think dean, me, dbaron, anyone else might meet to go through use cases
  1161. # [20:18] <fantasai> plinss: Think open issue Tab was going to write JS for is important here
  1162. # [20:18] <fantasai> dbaron: I don't think so
  1163. # [20:18] <fantasai> dbaron: That's internal to the transitions model, the reversing behavior
  1164. # [20:19] <fantasai> dbaron: No cascading behavior, not two different models interacting with each other
  1165. # [20:19] <fantasai> szilles: Why is interrupting a transition with a transition different from interrupting an animation with a transition?
  1166. # [20:20] <fantasai> dbaron: [something about different models]
  1167. # [20:20] <fantasai> szilles: As a user, how is it different?
  1168. # [20:20] <fantasai> dbaron: It's a much more important use case
  1169. # [20:20] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
  1170. # [20:20] <fantasai> dbaron: It's very common to interupt a :hover partway through a transition
  1171. # [20:21] <fantasai> plinss brings up case of animation ending, do you snap to base state
  1172. # [20:21] <fantasai> smfr: Yes. Never transition due to animation
  1173. # [20:21] <fantasai> plinss: So in that case, we shouldn't transition from any other animated state
  1174. # [20:21] <sylvaing> we do have a clause saying animating values do not cause transitions to start
  1175. # [20:21] <fantasai> plinss: See the logic of it. Not sure users would be happy with that.
  1176. # [20:22] <fantasai> szilles: Agree. Think users would like to be able to avoid flashing.
  1177. # [20:22] <fantasai> szilles: question is, is that some new L5 feature we add to handle that case?
  1178. # [20:22] <sylvaing> if people apply both an animation and a transition to something I think it's rational to believe they don't expect unanimated transitions between the two
  1179. # [20:23] <fantasai> ...
  1180. # [20:23] <sylvaing> or other visually janky switching
  1181. # [20:23] <fantasai> fantasai: You could have an animation-transition property :)
  1182. # [20:23] <fantasai> szilles: pick a simple solution for this, add something to patch it later
  1183. # [20:24] * sylvaing elika, no renaming until LC
  1184. # [20:24] <SteveZ> sylvain: rename "last call" to "renaming call"
  1185. # [20:25] * fantasai wasn't proposing to rename anything
  1186. # [20:25] * SimonSapin just renamed stuff in css3-page … but we had LCs in 2003 and 2006 so it’s fine.
  1187. # [20:25] * fantasai was proposing to add a aproperty, how is this a renaming discussion
  1188. # [20:25] <sylvaing> SteveZ, yes. Let us bikeshed on process step names!
  1189. # [20:25] * fantasai that's a terminology change, it doesn't count
  1190. # [20:25] * fantasai ^SimonSapin
  1191. # [20:26] <fantasai> ACTION dbaron: assign actions
  1192. # [20:26] * trackbot is creating a new ACTION.
  1193. # [20:26] <trackbot> Created ACTION-535 - Assign actions [on David Baron - due 2013-02-12].
  1194. # [20:26] * sylvaing right. if you add a property at LC its name is by definition correct. we should just wait for LC to define these things :)
  1195. # [20:26] <dbaron> ACTION dbaron meet with smfr and dino to come up with a proposed model for transitions/animations cascading and interaction
  1196. # [20:26] * trackbot is creating a new ACTION.
  1197. # [20:26] <trackbot> Created ACTION-536 - Meet with smfr and dino to come up with a proposed model for transitions/animations cascading and interaction [on David Baron - due 2013-02-12].
  1198. # [20:27] <dbaron> trackbot, mark ACTION-535 complete
  1199. # [20:27] <trackbot> Sorry, dbaron, I don't understand 'trackbot, mark ACTION-535 complete'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
  1200. # [20:27] <fantasai> Topic: F2F Tokyo
  1201. # [20:27] <jdaggett> http://wiki.csswg.org/planning/tokyo-2013
  1202. # [20:27] <dbaron> trackbot, close ACTION-535
  1203. # [20:27] * trackbot is closing ACTION-535.
  1204. # [20:27] <trackbot> Closed ACTION-535 Assign actions.
  1205. # [20:27] <fantasai> June 2013
  1206. # [20:27] <fantasai> Su Mo Tu We Th Fr Sa
  1207. # [20:27] <fantasai> 1
  1208. # [20:27] <fantasai> 2 3 4 5 6 7 8
  1209. # [20:27] <fantasai> 9 10 11 12 13 14 15
  1210. # [20:28] <fantasai> jdaggett: One complication, SVG wants to co-locate
  1211. # [20:28] <fantasai> jdaggett: Mozilla will sponsor both meetings
  1212. # [20:28] <fantasai> jdaggett: Multiple offers of ppl to host one or the other, but I think easier to keep on one site
  1213. # [20:28] <fantasai> jdaggett: Looks like Mozilla Japan will have a new office with room
  1214. # [20:28] <fantasai> jdaggett: So would like to pick dates
  1215. # [20:28] <dbaron> June 5-7 are the proposed dates
  1216. # [20:29] <dbaron> AC meeting is 9-11
  1217. # [20:29] * shepazu warns jdaggett that dates are sticky, and he should wash his hands after picking them
  1218. # [20:31] <dino> when is the SVG meeting?
  1219. # [20:31] <fantasai> RESOLVED: June 5-7 at Mozilla Japan in Tokyo
  1220. # [20:31] <jdaggett> dino: svg is discussing that this week
  1221. # [20:31] <jdaggett> dino: on friday i think
  1222. # [20:31] * fantasai notes that not many people responded to the doodle
  1223. # [20:31] <glazou> <br type="lunch" />
  1224. # [20:32] * dbaron fantasai, what doodle?
  1225. # [20:32] * fantasai http://doodle.com/z99cyshc5fy96kbr
  1226. # [20:32] <Bert> ACTION-535?
  1227. # [20:32] * trackbot is looking up ACTION-535.
  1228. # [20:32] <trackbot> ACTION-535 -- David Baron to assign actions -- due 2013-02-12 -- CLOSED
  1229. # [20:32] <trackbot> http://www.w3.org/Style/CSS/Tracker/actions/535
  1230. # [20:33] <dino> i agree it should give the link when creating. Maybe a shortlink? w3.org/q/2duoi4
  1231. # [20:34] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
  1232. # [20:36] * Bert counts 23 PERs
  1233. # [20:37] * Quits: smfr (~smfr@public.cloak) (smfr)
  1234. # [20:40] * mollyholzschlag test
  1235. # [20:43] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
  1236. # [20:55] * Joins: smfr (~smfr@public.cloak)
  1237. # [21:00] * Quits: tantek (~tantek@public.cloak) (tantek)
  1238. # [21:05] * plinss is now known as plinss_away
  1239. # [21:08] * plinss_away is now known as plinss
  1240. # [21:14] <dbaron> what happened to dvcs.w3.org?
  1241. # [21:14] <dbaron> It's giving my HTTP Error 500 Internal Server Error
  1242. # [21:14] <dbaron> s/my/me/
  1243. # [21:14] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  1244. # [21:14] * Joins: dbaron (~dbaron@public.cloak)
  1245. # [21:16] * Joins: jarek (~jarek@public.cloak)
  1246. # [21:23] * Quits: smfr (~smfr@public.cloak) (smfr)
  1247. # [21:29] * Joins: SimonSapin (~simon@public.cloak)
  1248. # [21:38] * Quits: sylvaing (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
  1249. # [21:42] * Joins: antonp (~Thunderbird@public.cloak)
  1250. # [21:50] * Joins: sylvaing (~sylvaing@public.cloak)
  1251. # [21:51] * Joins: nvdbleek (~nvdbleek@public.cloak)
  1252. # [21:55] * Joins: smfr (~smfr@public.cloak)
  1253. # [21:58] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
  1254. # [21:58] * Quits: koji (~koji@public.cloak) ("Page closed")
  1255. # [21:58] * Joins: koji (~koji@public.cloak)
  1256. # [22:01] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  1257. # [22:06] * Joins: isherman-book (~Adium@public.cloak)
  1258. # [22:06] * Joins: tantek (~tantek@public.cloak)
  1259. # [22:08] <mollyholzschlag> Heya - if you're speaking tonight take a moment and ping me your name or any details you want mentioned in your introduction
  1260. # [22:11] <fantasai> SimonSapin: Issue discussed at TPAC wrt multi-col
  1261. # [22:11] <fantasai> SimonSapin: Algorithm there has an idea of an unknown available width, and I think it doesn't make sense
  1262. # [22:11] <fantasai> SimonSapin: I tried to talk with Håkon and Bert, via email, F2F
  1263. # [22:11] <fantasai> SimonSapin: but seems we don't understand each other
  1264. # [22:11] <fantasai> glazou: Seems like adding to agenda is a good idea
  1265. # [22:11] <fantasai> szilles: Would also like to add exclusions update to agenda
  1266. # [22:11] <fantasai> SimonSapin: Related issue is that we have two different definitions for min-content and max-content
  1267. # [22:11] <fantasai> SimonSapin: One is sizing, and one in box module, and they are not compatible
  1268. # [22:11] <fantasai> SimonSapin: Discussed at TPAC... but still have two.
  1269. # [22:11] * Parts: glazou (~glazou@public.cloak) (glazou)
  1270. # [22:11] * Joins: glazou (~glazou@public.cloak)
  1271. # [22:12] * Joins: Rossen (~Rossen@public.cloak)
  1272. # [22:12] <fantasai> Topic: Fonts
  1273. # [22:12] <fantasai> jdaggett: First topic is case-sensitivity of font family names
  1274. # [22:12] <fantasai> jdaggett: Talked about this yesterday
  1275. # [22:12] <fantasai> jdaggett: I put last night wording into spec to define the exact algorithm to be used
  1276. # [22:13] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-family-casing
  1277. # [22:13] <fantasai> jdaggett: Would like to take a second to resolve on this
  1278. # [22:13] <fantasai> jdaggett: Points at default caseless matching algorithm in Unicode spec
  1279. # [22:13] <fantasai> jdaggett: You case-fold each string
  1280. # [22:13] <fantasai> jdaggett: Use case mappings defined by C/F statuses in CaseFoldingtxt
  1281. # [22:14] <fantasai> jdaggett: Noted there is no normalization, no locale-specific behavior
  1282. # [22:14] <fantasai> jdaggett: Another paragraph explains to authors where they should be careful
  1283. # [22:14] <fantasai> jdaggett: Most people won't be affected
  1284. # [22:15] <fantasai> smfr: Maybe 2nd paragraph should be a note
  1285. # [22:16] * Joins: mollyholzschlag_ (~mholzsch@public.cloak)
  1286. # [22:16] <fantasai> fantasai: Think the last sentence of 1st paragraph should be a note
  1287. # [22:16] <fantasai> jdaggett: Want to make sure implementers don't use the wrong pre-written methods
  1288. # [22:17] <fantasai> TabAtkins: Pulling it out into a note would actually make it more obvious
  1289. # [22:18] <fantasai> jdaggett: Implementations MUST NOT use platform routines that they don't understand.
  1290. # [22:18] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
  1291. # [22:18] * Quits: mollyholzschlag (~mholzsch@public.cloak) (Ping timeout: 60 seconds)
  1292. # [22:18] <fantasai> fantasai^: The normative requirements are already expressed in the paragraph, above. You're just pointing out that it's easy to screw up; this isn't a normative requirement, it's informative helpful advice
  1293. # [22:18] * mollyholzschlag_ is now known as mollyholzschlag
  1294. # [22:19] <fantasai> [discussion of normative, informative, notes, etc]
  1295. # [22:20] * glazou " this specification requires a minimal neuronal mass from the reader, please check your eligibility first " ?-)
  1296. # [22:21] <fantasai> jdaggett: Another issue is wrt default [?]
  1297. # [22:21] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#language-specific-support
  1298. # [22:22] <fantasai> jdaggett: This deals with language-specific features
  1299. # [22:22] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
  1300. # [22:22] <fantasai> jdaggett: Question is, whether UAs should by default always use the default system, or huse heuristics to guess language
  1301. # [22:23] <fantasai> fantasai: You defer to the "document language"
  1302. # [22:23] <fantasai> fantasai: If it's unknown, use default. Don't guess
  1303. # [22:23] * TabAtkins_ plinss: I'll be back in a sec, but when jdaggett is done, I'd like to go through the remaining Counter Style issues and request LC.
  1304. # [22:24] <fantasai> jdaggett: HTML5 explicitly says that if it's not sepcified, it's unknown
  1305. # [22:24] <fantasai> [...]
  1306. # [22:25] <fantasai> jdaggett: So if it's not known, what do we do?
  1307. # [22:25] <fantasai> fantasai: Is the language a required param to the API calls?
  1308. # [22:25] <fantasai> jdaggett: No.
  1309. # [22:25] <fantasai> fantasai: Then don't pass a language.
  1310. # [22:25] <fantasai> fantasai: If the author wanted lang-specific features, should have put a lang tag
  1311. # [22:26] <fantasai> ...
  1312. # [22:26] <fantasai> [discussion of mapping ISO lang codes to OpenType lang systems]
  1313. # [22:26] <fantasai> jdaggett: For most things, you can map. If you want to override, you can also override
  1314. # [22:26] <fantasai> Glenn: ... script ...
  1315. # [22:26] <fantasai> jdaggett: This is given by character code
  1316. # [22:27] <SimonSapin> HTML "language of a node" http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#language
  1317. # [22:27] <fantasai> glenn: Opentype indic have two scripts defined, one for older tables and one for newer tables
  1318. # [22:27] <fantasai> glenn: Since we don't have a way for authors to define script specifically, we have a gray box here..
  1319. # [22:27] <fantasai> glenn: I would suggest treating the whole problem space is
  1320. # [22:27] <fantasai> jdaggett: So define default script as well as default language?
  1321. # [22:28] <fantasai> glenn: You need three tags to generate the tables that apply
  1322. # [22:28] <fantasai> glenn: script, language, ?
  1323. # [22:28] <fantasai> s/?/feature
  1324. # [22:28] <fantasai> jdaggett: We have a set of properties dictating...
  1325. # [22:28] <fantasai> glenn: For a given set of features, leaves script and language as parameters
  1326. # [22:28] <fantasai> glenn: If you want to fully hanlde this mapping, then you need to define all three of these
  1327. # [22:28] <fantasai> glenn: Do you have language for dealing with script tag?
  1328. # [22:29] <fantasai> jdaggett: what's explained to me is that in general, script tag can be inferred from the codepoint
  1329. # [22:29] <fantasai> jdaggett: Some issue with different versions of indic, but for given implementation, you're picking one and using that one
  1330. # [22:29] <fantasai> jdaggett: Using one or the other
  1331. # [22:29] <fantasai> glenn: I'm aware of one implementation, because I did it, in XSL:FO, allow to specify script identifier based on ISO script identification system
  1332. # [22:30] <fantasai> glenn: So I happen to implement the ability to allow author to specify variants in order to select between old indic vs. new indic
  1333. # [22:30] <fantasai> glenn: If you look for indic fonts, some built for first version, some for second, some to support both
  1334. # [22:30] <fantasai> jdaggett: Those tables can be looked up
  1335. # [22:30] <fantasai> jdaggett: You're sort of overspecifying by pushing out into author space
  1336. # [22:30] <fantasai> glenn: Just want to make sure script tag mapping is discussed
  1337. # [22:30] <fantasai> jdaggett: I thought it was just an implementation detail, didn't need to be author-facing
  1338. # [22:31] <fantasai> jdaggett: Think I might leave this open, since nobody else is speaking up
  1339. # [22:31] <fantasai> glenn: I agree with fantasai that you should defer to document language at first order
  1340. # [22:31] <fantasai> glenn: We should make sure there's a well-defined mapping between the tag sets
  1341. # [22:31] <fantasai> glenn: Also begs question of lang tags for non-OT fonts, not sure we need to get into that
  1342. # [22:32] <fantasai> jdaggett: Think we need to make sure it works for OT, implementers can fill in the dots for other formats.
  1343. # [22:32] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
  1344. # [22:32] <fantasai> fantasai: Would like to point outUsers agents are required to infer the OpenType language system from the value of the ‘lang’ attribute
  1345. # [22:33] <fantasai> fantasai: Should just defer to document language, not specify how it's found.
  1346. # [22:33] <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/70
  1347. # [22:33] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Sep/0197.html
  1348. # [22:33] <fantasai> jdaggett: I went in to fonts spec and put in prose to handle all the cases, but never cleared out the issue
  1349. # [22:34] <fantasai> jdaggett: Has to do with the ay certain combinations of say questin marks, what the semantics of that are
  1350. # [22:34] <fantasai> jdaggett: In the spec, a number of statements about this
  1351. # [22:34] <fantasai> jdaggett: Was a conflict with the way the syntax spec was worded, but that's ironed out before lunch
  1352. # [22:34] <fantasai> jdaggett: So, unless anyone sees anything here, I'd like to close this issue
  1353. # [22:34] <fantasai> jdaggett: Can always raise another issue if there's something specific to handle
  1354. # [22:34] <Bert> -> http://www.w3.org/TR/selectors/#lang-pseudo Selectors text about what is an element's language
  1355. # [22:34] <fantasai> jdaggett: Think we've fixed all the problems in this issue
  1356. # [22:35] <fantasai> SimonSapin: Think Syntax solves the parsing-related issues
  1357. # [22:35] <fantasai> dbaron: Might be worth sending something to Zack
  1358. # [22:35] <fantasai> RESOLVED: Close ISSUE-70, ping Zack about this
  1359. # [22:35] <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/71
  1360. # [22:36] <fantasai> trackbot, close ISSUE-70
  1361. # [22:36] * trackbot is closing ISSUE-70.
  1362. # [22:36] <trackbot> Closed ISSUE-70 UNICODE-RANGE definitions.
  1363. # [22:36] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Nov/0077.html
  1364. # [22:36] <fantasai> jdaggett: Spec now has prose to talk about this
  1365. # [22:37] <fantasai> jdaggett: Gecko implementation doesn't implement 'unicode-range', so part of reason for difference in behavior [...]
  1366. # [22:37] <fantasai> jdaggett: Think most issues have been dealt with in the spec
  1367. # [22:37] <fantasai> jdaggett: Can open new bugs if more specific things are found
  1368. # [22:38] <glenn> http://lists.w3.org/Archives/Public/www-style/2009Jan/0173.html
  1369. # [22:38] <dbaron> that's CSS 2.1 issue 71, not tracker issue 71
  1370. # [22:39] <fantasai> fantasai: if dbaron's happy, I'm happy
  1371. # [22:39] <fantasai> dbaron: Fine with closing it. May some point look at the text and comment
  1372. # [22:40] <fantasai> jdaggett: Font loader issues, but defer that... want WebApps people to comment on some of those things
  1373. # [22:40] <fantasai> jdaggett: Other than the language issue, I did make one change...
  1374. # [22:43] <fantasai> [some discussion about error handlers]
  1375. # [22:43] * Joins: jarek_ (~jarek@public.cloak)
  1376. # [22:43] <fantasai> jdaggett: You have to load content, and start laying it out, to assess whether you need to download a font
  1377. # [22:43] <fantasai> jdaggett: Could start loading a font via JS, but, then that's your won problem
  1378. # [22:43] <fantasai> s/won/own/
  1379. # [22:44] <fantasai> jdaggett: Is there a scenario you're concerned about?
  1380. # [22:44] <fantasai> glenn: Is there a way to register to handler using onerror attribute?
  1381. # [22:44] <fantasai> jdaggett: Yes, there are both event handler attributes plus you can use the event handler name
  1382. # [22:44] * Quits: jarek (~jarek@public.cloak) (Ping timeout: 60 seconds)
  1383. # [22:44] <fantasai> glenn: So element directly attach tto font loader, woudl that be body?
  1384. # [22:44] <fantasai> jdaggett: document
  1385. # [22:44] <fantasai> jdaggett: This is all in the spec
  1386. # [22:44] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-style-matching
  1387. # [22:44] <fantasai> jdaggett: Section I want to look at is cluster matching
  1388. # [22:45] <fantasai> jdaggett: I put in some wiggle room for specific scenario that sometimes occurs
  1389. # [22:45] <fantasai> jdaggett [quotes spec]
  1390. # [22:46] <fantasai> jdaggett: This is a compat issue with the way Arial has implemented Arabic in the past
  1391. # [22:46] <fantasai> jdaggett: Where they have Arabic glyphs in the default face, but not the italic face
  1392. # [22:46] <fantasai> jdaggett: So if you say italic Arial, you get fallback
  1393. # [22:46] <fantasai> in some browsers
  1394. # [22:46] <fantasai> jdaggett: This allows creating synthetic italics
  1395. # [22:46] <fantasai> jdaggett: Avoid searching all faces
  1396. # [22:47] <fantasai> jdaggett: The added wording, "The only exception ..."
  1397. # [22:47] <fantasai> Bert: Default face is the roman face?
  1398. # [22:47] <fantasai> jdaggett: What you would select if you had all font properties set to initial value
  1399. # [22:48] <fantasai> jdaggett: Unless there's other issues to bring up, would propose publishing another WD
  1400. # [22:48] <fantasai> jdaggett: Was hoping this woudl be LC, but I'm uncomfortable with the way font loader is right now, and want WebApps people to look it over first
  1401. # [22:49] <fantasai> jdaggett: It's an unusual section for a CSS spec b/c defines API with scripting behavior
  1402. # [22:49] <fantasai> jdaggett: So would like to have other people review it
  1403. # [22:49] <fantasai> jdaggett: But that is my intent, review things, then go to LC
  1404. # [22:49] <fantasai> jdaggett: Hopefully within this month
  1405. # [22:49] <fantasai> fantasai: There's an issue raised on italics and vertical text that probably warrants some discussion as well
  1406. # [22:49] <fantasai> jdaggett: Think we shouldn't deal with that in this level
  1407. # [22:49] <fantasai> jdaggett: From your post, Koji, don't see that there's a clear desired behavior
  1408. # [22:50] <jdaggett> http://koji.ec/archives/7
  1409. # [22:50] <fantasai> jdaggett: In vertical text runs, when you say "italic", most Japanese fonts don't have an italic face, so what is produced is a synthetic oblique face
  1410. # [22:51] <fantasai> jdaggett: There were two issues in the mail he wrote
  1411. # [22:51] <fantasai> jdaggett: One is, what is the right way to do synthetic italics for Latin in vertical
  1412. # [22:51] <fantasai> jdaggett: UAs always oblique to the right. If not right for RTL, could add ways of obliquing to the lft
  1413. # [22:51] <fantasai> jdaggett: Tricky one is what to do about vertical text runs, where the obliquing is distinctly different
  1414. # [22:52] <fantasai> jdaggett: If you look at the picture
  1415. # [22:52] <fantasai> jdaggett: 1 is what you get by default
  1416. # [22:52] <fantasai> jdaggett: different processor swill give you different results, depending on what you want to do
  1417. # [22:52] <fantasai> jdaggett: I think Koji said IE10 does 6 and Webkit does 8
  1418. # [22:53] <fantasai> jdaggett: From my perspective of just defining what italics should map to, I think 8 is correct
  1419. # [22:53] <fantasai> jdaggett: However, maybe patterns in Japanese publishing where e.g. 3 or 4 are considered the norm
  1420. # [22:53] <fantasai> jdaggett: However, I think they require a different property to solve correctly
  1421. # [22:53] <fantasai> jdaggett: Might be a good feature to allow shear transforms on individual glyphs
  1422. # [22:53] <fantasai> jdaggett: But don't think we should do this in this level
  1423. # [22:54] <fantasai> jdaggett: Fact that there are 8 different renderings
  1424. # [22:54] <fantasai> jdaggett: Shows there is a deeper issue, can't be solved by us declaring which one is right
  1425. # [22:54] <fantasai> jdaggett: Can take an action to get more opinion on this
  1426. # [22:54] <fantasai> jdaggett: Dont' think we'll get a good sampling of opinion on www-style
  1427. # [22:54] <fantasai> plinss: Where do these renderings come from?
  1428. # [22:54] <fantasai> Koji: I did it by transform
  1429. # [22:54] * Joins: mollyholzschlag_ (~mholzsch@public.cloak)
  1430. # [22:54] <fantasai> Koji: This picture is generated by transforms
  1431. # [22:55] <fantasai> Koji: But tested what actual results are in other implementations
  1432. # [22:56] <fantasai> jdaggett: Problem in spec is inconsistency among browsers, not sure we should be looking at other implementations
  1433. # [22:56] <fantasai> jdaggett: Koji says we should define what synthetic italic looks like
  1434. # [22:56] <fantasai> plinss: Is italic used with japanese glyphs?
  1435. # [22:56] <fantasai> jdaggett: Not common, but it happens
  1436. # [22:57] <fantasai> jdaggett: For Japanes text, if you have italics, and don't oblique it, people file bugs
  1437. # [22:57] * Quits: mollyholzschlag (~mholzsch@public.cloak) (Ping timeout: 60 seconds)
  1438. # [22:57] * mollyholzschlag_ is now known as mollyholzschlag
  1439. # [22:57] <fantasai> plinss: Is it every correct to oblique the text?
  1440. # [22:57] <fantasai> jdaggett: If there's a pattern of text obliqued, should investigate/do somethign about that
  1441. # [22:57] <fantasai> jdaggett: but not for this level
  1442. # [22:58] * Quits: jarek_ (~jarek@public.cloak) (jarek_)
  1443. # [22:58] <dbaron> to my eyes, the difference between 2 and 8 is very subtle
  1444. # [22:58] <dbaron> (but I do now see it)
  1445. # [22:59] <fantasai> fantasai: I would like more evidence from printed matter that there's one pattern that's always used
  1446. # [23:01] <fantasai> s/fantasai/jdaggett/
  1447. # [23:01] <fantasai> fantasai: CSS3 Fonts requires synthesizing italics, question here is, if used in vertical text, then what do you synthesize?
  1448. # [23:01] <fantasai> jdaggett, szilles: just leave it undefined
  1449. # [23:02] <fantasai> jdaggett: Disagree that this blog post is enough to make a decision on the right default
  1450. # [23:03] <fantasai> fantasai: Even if we add a property for this, what would be the initial value?
  1451. # [23:03] <dbaron> dbaron: Experimentation might lead to a bunch of UAs being willing to switch to another's behavior because it's better.
  1452. # [23:04] <fantasai> jdaggett: I'll see if there's more published examples of this being used consistently, but unless that comes back with a solid answer of "you always do this"...
  1453. # [23:05] <fantasai> szilles: Also have problem that this is Japanese, what about Chinese
  1454. # [23:05] <fantasai> fantasai: The preferred slant is derived from the more cursive forms of Han characters, so would be consistent.
  1455. # [23:06] <fantasai> ...
  1456. # [23:06] <fantasai> koji: If I specify italic, want consistent behavior across browsers.
  1457. # [23:06] <fantasai> jdaggett: If there's variation...
  1458. # [23:06] <fantasai> koji: There is variation in typographic world.
  1459. # [23:06] <fantasai> koji: Pick an interoperable consistent default behavior.
  1460. # [23:07] <fantasai> jdaggett: It's not a commonly used feature. Might be just accident of implementation.
  1461. # [23:07] <fantasai> koji: Can add features in future. Want the baseline behavior to be consistent.
  1462. # [23:07] <fantasai> koji: My preference is to use 6, because it's what word processors do and people are used to it
  1463. # [23:08] <fantasai> jdaggett: Would prefer not to standardize on what a publisher would not do
  1464. # [23:08] <fantasai> koji: Publishers want more controls, fine to do in Level 4
  1465. # [23:08] <fantasai> jdaggett: Think this needs more research
  1466. # [23:09] <fantasai> fantasai: Assume there is a variety of needs. What is the default?
  1467. # [23:09] <fantasai> szilles: It's UA-defined.
  1468. # [23:10] <fantasai> kawabata-san and koji are not happy with this
  1469. # [23:10] <fantasai> kawabata-san: Is there a difference in slanting between LTR or RTL?
  1470. # [23:10] <fantasai> j Today there is not. Could argue that this is not ideal behavior.
  1471. # [23:10] <fantasai> jd Existing bheavior for syntehtic obliques is consistent.
  1472. # [23:10] <fantasai> glenn: italics don't apply to Arabic anyway
  1473. # [23:11] <fantasai> jdaggett: It's an artifact of word processors
  1474. # [23:11] <fantasai> fantasai: Some precedent for italics in Hebrew though
  1475. # [23:12] <fantasai> koji: I'm happy not to make conclusion here, happy to publish WD, as long as this is kept as an open issue.
  1476. # [23:12] <fantasai> fantasai^: Following the logic of RTL, where slant is always consistent, why not make writing mode also stay consistent.
  1477. # [23:13] <dbaron> the right side of http://www.huji.ac.il/ shows what looks to me like Italic style in Hebrew
  1478. # [23:13] <fantasai> RESOLVED: Publish WD
  1479. # [23:13] <fantasai> RTL italics discussion: http://typophile.com/node/49385?page=2
  1480. # [23:13] <dbaron> (and it's an image, too)
  1481. # [23:13] <fantasai> Chinese mixing fonts in Roman/Italics pattern: http://fantasai.inkedblade.net/style/scans/Princeton%20East%20Asian%20Library%20-%20ZhongGuoYin__Xue%202005.4%20001.png
  1482. # [23:14] <fantasai> jdaggett: Please review the draft, particularly wrt functionality
  1483. # [23:14] <fantasai> szilles: Meaning correct definition of the functionalities there, not what's missing
  1484. # [23:14] <fantasai> fantasai: No new features. But if things are unintentionally undefined, should be an issue
  1485. # [23:15] * heycam|away is now known as heycam
  1486. # [23:15] <fantasai> <br type="tea"/>
  1487. # [23:16] * Joins: cabanier (~cabanier@public.cloak)
  1488. # [23:19] <jdaggett> fantasai: that's a simple mixing of brush styles
  1489. # [23:20] <jdaggett> fantasai: comparing it to roman/italic is an oversimplification
  1490. # [23:23] <jdaggett> feedback on faux oblique from nat at adobe:
  1491. # [23:23] <jdaggett> In my opinion 斜体 is totally different from italic, or even oblique, in usage and applicability to Latin typographic convention.
  1492. # [23:23] <jdaggett> "In InDesign we keep them totally separate."
  1493. # [23:24] <jdaggett> "There is no italic in Japanese, no need to faux oblique with Japanese using slant, in fact only slanting is wrong, so just don't do it."
  1494. # [23:24] <jdaggett> "Use 斜体 instead which scales, rotates, and shears with precise settings."
  1495. # [23:28] <koji> I agree with Nat. The point here is, if publishing industry doesn't need italics at all, and if all word processor vendors/users requires it, why don't we suffice word processor users in level 3, and pursue publishing industry in level 4?>
  1496. # [23:32] <jdaggett> if there's consistent behavior that is in common use then we can use that
  1497. # [23:34] * Quits: mollyholzschlag (~mholzsch@public.cloak) ("sleeping computer is sleeping")
  1498. # [23:36] * plinss is now known as plinss_away
  1499. # [23:36] <koji> An example HTML file at http://dl.dropbox.com/u/8812114/italics-vertical.htm
  1500. # [23:37] * plinss_away is now known as plinss
  1501. # [23:39] <koji> jdaggett: yes, I'll collect actual examples from word processor market to get to you
  1502. # [23:40] <jdaggett> we need actual use cases from users
  1503. # [23:40] <jdaggett> not just testcases that use the feature
  1504. # [23:41] <Bert> ScribeNick: Bert
  1505. # [23:41] <Bert> Topic: counter styles
  1506. # [23:42] <Bert> TabAtkins_: [looking up the issues]
  1507. # [23:42] <TabAtkins_> http://dev.w3.org/csswg/css-counter-styles-3/#alphabetic-system
  1508. # [23:42] <Bert> TabAtkins_ : section 5
  1509. # [23:42] <Bert> ... example 6
  1510. # [23:43] <Bert> ... Fixed with counter style, example
  1511. # [23:43] <Bert> ... It's a hack
  1512. # [23:43] <Bert> ... Is this important enought to add a fixed width system?
  1513. # [23:43] <Bert> fantasai: This is not good practice.
  1514. # [23:43] <Bert> ... If we do them, let's do them properly
  1515. # [23:44] <Bert> ... Reading from a screen reader, or something, gets the wrong values.
  1516. # [23:44] <Bert> glazou: They read 0-0-0-3
  1517. # [23:44] <Bert> fantasai: you want the to read "3"
  1518. # [23:44] <Bert> TabAtkins_: Just remove it? Or add fixed width system?
  1519. # [23:44] <Bert> glazou: The latter
  1520. # [23:45] <Bert> TabAtkins_: And waht about negative values and out of range?
  1521. # [23:45] <Bert> fantasai: Say fill with how many digits.
  1522. # [23:45] <Bert> TabAtkins_: nagative prefix
  1523. # [23:45] <Bert> Stevez: another sign position
  1524. # [23:45] <Bert> ... Need to say if you have space for sign or not.
  1525. # [23:46] <Bert> ... Can ad a value 'sign' to say you want space for sign.
  1526. # [23:46] <Bert> ... So that neg values still same width.
  1527. # [23:46] <Bert> fantasai: May then prefixx it with spaces.
  1528. # [23:46] <Bert> SteveZ: And for overflow, just overflow.
  1529. # [23:46] <Bert> TabAtkins_: OK, I'll do that.
  1530. # [23:46] <Bert> TabAtkins_: Sect 3.5,
  1531. # [23:47] <Bert> ... issue 2
  1532. # [23:47] <dbaron> http://dev.w3.org/csswg/css-counter-styles-3/#counter-style-range
  1533. # [23:47] <Bert> ... Infinite range obviously not actually supported.
  1534. # [23:47] <Bert> ... should we specify a minimum required range?
  1535. # [23:48] <Bert> ... Something liek at least 16 bits?
  1536. # [23:48] <Bert> TabAtkins_: A nice base-2 number?
  1537. # [23:48] <Bert> fantasai: more than 256!
  1538. # [23:48] <Bert> TabAtkins_: Yes, 2 bytes or so
  1539. # [23:49] <Bert> fantasai: We discussed this elswehere, too.
  1540. # [23:49] <Bert> TabAtkins_: Currently between 16 and 32 bits
  1541. # [23:49] <Bert> ... 16 bits shoul dmake everyne happy.
  1542. # [23:49] <Bert> ... Nobody actually 32, maybe 31 bits
  1543. # [23:49] <Bert> Rossen: [missed]
  1544. # [23:49] <Bert> TabAtkins_: Easier to test with required range
  1545. # [23:50] <Bert> SteveZ: Need ten to change implem that go beyond it.
  1546. # [23:50] <Bert> dbaron: We have 32 bit signed int.
  1547. # [23:50] <Bert> TabAtkins_: Opera something like 2 billion
  1548. # [23:50] <Bert> fantasai: That's more than we need.
  1549. # [23:51] <Bert> SteveZ: No, it';s not. Machines generate more than that.
  1550. # [23:51] <Bert> dbaron: Yes, I can imagine that
  1551. # [23:51] <Bert> plinss: Can also start a count at 20mln and than have only 20 entries.
  1552. # [23:51] <Bert> fantasai: 3 bytes, then?
  1553. # [23:51] <Bert> plinss: Should we have a minimum range?
  1554. # [23:52] <Bert> SteveZ: Yes, we can always raise it.
  1555. # [23:52] <Bert> TabAtkins_: Yes
  1556. # [23:52] <Bert> SteveZ: Not clamp it.
  1557. # [23:52] <Bert> tantek: Unit length: what did we decide?
  1558. # [23:52] <Bert> TabAtkins_: Doesn't require a range right now.
  1559. # [23:52] <Bert> ... We couldn't get consistent answer in time.
  1560. # [23:53] <Bert> tantek: We are going to LC?
  1561. # [23:53] <Bert> TabAtkins_: yes
  1562. # [23:53] <Bert> ... Length are more complicated
  1563. # [23:53] <Bert> fantasai: They can be floats as well.
  1564. # [23:53] <Bert> TabAtkins_: And inches and pixels not same range.
  1565. # [23:53] <Bert> TabAtkins_: Should I pick 2 bytes?
  1566. # [23:53] <Bert> dbaron: Fne as a minimum.
  1567. # [23:54] <Bert> SimonSapin: [missed]
  1568. # [23:54] <Bert> plinss: Should not wrap.
  1569. # [23:54] <Bert> TabAtkins_: yes
  1570. # [23:54] <Bert> glenn: [smagic number that scribe didn't catch]
  1571. # [23:54] <dbaron> 1114112
  1572. # [23:54] <dbaron> (17 * 2^16)
  1573. # [23:54] <fantasai> RESOLVED: 2-byte minimum, clamp, no wrap
  1574. # [23:55] <fantasai> TabAtkins: Whenever you hit your maximum, clamp to that instead of wrapping into negatives
  1575. # [23:55] <Bert> TabAtkins_: When you read the top, don't wrap, just stop there.
  1576. # [23:56] <Bert> dbaron: It's about counter-reset with some value
  1577. # [23:56] <Bert> SteveZ: Incrementing a clamped value doens't increment it.
  1578. # [23:56] <Bert> ... Incrementing maximum value has no effect.
  1579. # [23:56] <Bert> dbaron: You can increment with more than 1
  1580. # [23:57] <Bert> ... So have to say you become the maximum.
  1581. # [23:57] <Bert> plinss: Othe roption is to stay and not incr.
  1582. # [23:57] <dbaron> Peter: so if the increment would put you over the maximum, do you increment to the maximum, or stay where you are?
  1583. # [23:57] <Bert> SteveZ: Can also say that, increment that would go beyond does nothng.
  1584. # [23:57] <SimonSapin> s/[missed]/More important than a minimum range is to define what to do what an implementation-specific range is reached/
  1585. # [23:58] <Bert> plinss: Say you're at max-i and incrmeent is 100
  1586. # [23:58] <Bert> ... Should not go beyond max
  1587. # [23:58] <Bert> dbaron: OK with that
  1588. # [23:58] <SimonSapin> s/max-i/max-1/
  1589. # [23:58] <SimonSapin> s/go beyond max/go to max/
  1590. # [23:58] <Bert> RESOLVED: if current value + increment is outside of the range, then do not increment
  1591. # [23:59] <TabAtkins_> test
  1592. # [23:59] <Bert> TabAtkins_: issue about fallback style
  1593. # [23:59] <Bert> ... For styles with linted range.
  1594. # [23:59] <Bert> ... e.g., circled numberd in Unciode.
  1595. # [23:59] <Bert> ... You normally drop back to decimal.
  1596. # Session Close: Wed Feb 06 00:00:00 2013

The end :)