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

Options:

  1. # Session Start: Wed May 05 00:00:00 2010
  2. # Session Ident: #css
  3. # [00:59] * Joins: miketaylr (miketaylr@24.42.95.234)
  4. # [01:20] * Quits: estellevw (estellevw@76.202.159.123) (Quit: going to hang out with the bunny rabbits)
  5. # [01:52] * Joins: anne2 (annevk@114.48.4.11)
  6. # [02:26] * Quits: anne2 (annevk@114.48.4.11) (Ping timeout)
  7. # [03:06] * Quits: miketaylr (miketaylr@24.42.95.234) (Quit: Leaving...)
  8. # [03:17] * Joins: miketaylr (miketaylr@24.42.95.234)
  9. # [03:37] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  10. # [04:10] * Quits: Curt` (DorkeyDear@76.243.210.242) (Quit: Leaving)
  11. # [05:33] * Quits: miketaylr (miketaylr@24.42.95.234) (Client exited)
  12. # [05:45] * Joins: myakura (myakura@220.104.128.62)
  13. # [05:52] * Joins: TabAtkins__ (chatzilla@76.253.3.102)
  14. # [06:14] * Quits: myakura (myakura@220.104.128.62) (Quit: Leaving...)
  15. # [06:25] * Joins: dbaron (dbaron@98.234.51.190)
  16. # [07:44] * Quits: TabAtkins__ (chatzilla@76.253.3.102) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.13/2009073109])
  17. # [08:35] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  18. # [11:04] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  19. # [11:26] * Joins: Lachy (Lachlan@213.236.208.22)
  20. # [12:51] * Joins: myakura (myakura@220.104.128.62)
  21. # [12:52] * Disconnected
  22. # [12:53] * Attempting to rejoin channel #css
  23. # [12:53] * Rejoined channel #css
  24. # [12:53] * Topic is 'CSS WG -- logs: http://krijnhoetmer.nl/irc-logs/css -- blog: http://www.w3.org/blog/CSS'
  25. # [12:53] * Set by anne on Thu Mar 11 21:03:19
  26. # [15:01] * Joins: jdaggett (jdaggett@118.243.224.63)
  27. # [15:01] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
  28. # [15:01] * Joins: jdaggett (jdaggett@118.243.224.63)
  29. # [15:05] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
  30. # [15:05] * Joins: jdaggett (jdaggett@118.243.224.63)
  31. # [15:05] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
  32. # [15:05] * Joins: jdaggett (jdaggett@118.243.224.63)
  33. # [15:21] * Joins: miketaylr (miketaylr@38.117.156.163)
  34. # [15:53] * Joins: ChrisL (ChrisL@128.30.52.169)
  35. # [16:28] * Quits: myakura (myakura@220.104.128.62) (Quit: Leaving...)
  36. # [16:33] * Joins: myakura (myakura@220.104.128.62)
  37. # [16:40] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  38. # [16:42] * Joins: Lachy (Lachlan@213.236.208.22)
  39. # [16:44] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  40. # [17:10] * Quits: shepazu (schepers@128.30.52.169) (Client exited)
  41. # [17:11] * Joins: shepazu (schepers@128.30.52.169)
  42. # [17:15] * Joins: bradk (bradk@67.188.133.45)
  43. # [17:44] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
  44. # [17:53] * Joins: sylvaing (sylvaing@76.104.131.10)
  45. # [17:54] * Joins: glazou (glazou@82.247.96.19)
  46. # [17:54] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  47. # [17:54] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  48. # [17:54] <RRSAgent> logging to http://www.w3.org/2010/05/05-CSS-irc
  49. # [17:54] <glazou> Zakim, this will be Style
  50. # [17:54] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 8 minutes
  51. # [17:55] <glazou> RRSAgent, make logs public
  52. # [17:55] <RRSAgent> I have made the request, glazou
  53. # [17:58] * Joins: oyvind (oyvinds@213.236.208.22)
  54. # [18:00] <Zakim> Style_CSS FP()12:00PM has now started
  55. # [18:00] <Zakim> +plinss
  56. # [18:01] <Zakim> +[IPcaller]
  57. # [18:01] * Joins: dbaron (dbaron@98.234.51.190)
  58. # [18:01] <jdaggett> zakim, ipcaller is jdaggett
  59. # [18:01] <Zakim> +jdaggett; got it
  60. # [18:01] <Zakim> +glazou
  61. # [18:01] <Zakim> +dsinger
  62. # [18:02] * Joins: dsinger_ (mobile@67.218.109.218)
  63. # [18:02] <dsinger_> zakim, who is on the phone?
  64. # [18:02] <Zakim> On the phone I see plinss, jdaggett, glazou, dsinger
  65. # [18:02] <Zakim> +bradk
  66. # [18:02] <dsinger_> zakim, mute dsinger
  67. # [18:02] <Zakim> dsinger should now be muted
  68. # [18:02] <Zakim> +TabAtkins
  69. # [18:02] <Zakim> +sylvaing
  70. # [18:02] * dsinger_ morning all!
  71. # [18:03] <bradk> good morning
  72. # [18:03] <Zakim> +[Microsoft]
  73. # [18:03] * Joins: szilles (chatzilla@192.150.10.200)
  74. # [18:03] <arronei> zakim, Microsoft is me
  75. # [18:03] <Zakim> +arronei; got it
  76. # [18:04] <Zakim> +David_Baron
  77. # [18:05] * dsinger_ silence is go-olden
  78. # [18:05] <Zakim> +??P18
  79. # [18:05] <Zakim> +SteveZ
  80. # [18:06] * dsinger_ who is p18?
  81. # [18:07] <Zakim> +smfr
  82. # [18:07] <dbaron> Zakim, ??P18 is fantasai
  83. # [18:07] <Zakim> +fantasai; got it
  84. # [18:07] * dbaron Zakim, who is noisy?
  85. # [18:07] * Zakim dbaron, listening for 10 seconds I could not identify any sounds
  86. # [18:08] * dsinger_ buz buz
  87. # [18:08] <tabatkins> ScribeNick: tabatkins
  88. # [18:08] <tabatkins> plinss_: Anything on the agenda?
  89. # [18:09] <tabatkins> plinss_: First topic: test suite status
  90. # [18:09] * Joins: ChrisL (ChrisL@128.30.52.169)
  91. # [18:09] * Joins: smfr (smfr@17.203.14.12)
  92. # [18:09] <tabatkins> arronei: I've made good progress on tagging all test cases, and am still on track to have them all tagged/checked in this friday.
  93. # [18:09] * Quits: myakura (myakura@220.104.128.62) (Quit: Leaving...)
  94. # [18:10] <tabatkins> fantasai: I talked with Richard about the i18n tests. He's in India right now, and he'll get back to me next week. For now I'm going to work on getting the reftests in, then I'll work on getting Hixie's test into a format we can use. The conversion shouldn't take too long, but there may be some missing files somewhere.
  95. # [18:10] <tabatkins> arronei: I may be able to find them. We'll figure it out.
  96. # [18:10] <tabatkins> plinss_: Sounds like progress is being made.
  97. # [18:10] <Zakim> +ChrisL
  98. # [18:11] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0553.html
  99. # [18:11] <tabatkins> plinss_: Font issues.
  100. # [18:11] <tabatkins> jdaggett: We went through a bunch of these.
  101. # [18:11] <tabatkins> jdaggett: We got through part of Bert's comments last week, through point G.
  102. # [18:11] <tabatkins> jdaggett: Remaining ones are h through k.
  103. # [18:11] <tabatkins> jdaggett: H is titling-caps. It's not really ideally specced, it's really "titling form".
  104. # [18:12] <tabatkins> jdaggett: There was a suggestion from John Hudson about how to rewrite that.
  105. # [18:12] <tabatkins> jdaggett: Part I, I went through and changed some of the values [didn't catch the exact values]
  106. # [18:12] <fantasai> from e.g. lining-nums to lining-numberals
  107. # [18:12] <tabatkins> jdaggett: ChrisL, you said you think just doing nums would be fine?
  108. # [18:12] <fantasai> s/numberal/numeral/
  109. # [18:12] <tabatkins> ChrisL: Yeah, I think it's fine.
  110. # [18:13] <tabatkins> plinss_: I think in general we should spell things out. If it's a well-known abbreviation or shortening, ok, but otherwise lets just use the longform.
  111. # [18:14] <tabatkins> szilles: I think that "num" is an abbreviation for "number", not "numeral", and the two things are different.
  112. # [18:14] <tabatkins> fantasai: I don't see a difference, but I'm not a typographer.
  113. # [18:14] <bradk> lining-numes?
  114. # [18:14] <tabatkins> jdaggett: So, steve, you'd prefer "numeral" to be spelled out?
  115. # [18:14] * dsinger_ a number is the idea of 2, whereas numeral might be roman
  116. # [18:15] * dsinger_ ie it is the representation
  117. # [18:15] * sylvaing you can't tell apart french people either. coincidence ?
  118. # [18:15] * tabatkins do french people have extra Bs?
  119. # [18:15] <tabatkins> jdaggett: I'll leave it as "num" for now, until someone has stronger objections.
  120. # [18:15] * sylvaing just lots of vowels
  121. # [18:16] <tabatkins> jdaggett: Point j is wrong, the fraction is a unicode feature.
  122. # [18:16] <tabatkins> jdaggett: Point k I put in to describe what it was, though it's really something for the webfonts group to talk about.
  123. # [18:16] <tabatkins> jdaggett: I just didn't see why Bert thought this violated the web architecture.
  124. # [18:17] <tabatkins> jdaggett: I don't think this is something to go into at great depth; the fonts group will talk about it, and then we can clarify it in our spec.
  125. # [18:17] * dbaron Zakim, who is on the phone?
  126. # [18:17] * Zakim sees on the phone: plinss, jdaggett, glazou, dsinger (muted), bradk, TabAtkins, sylvaing, arronei, David_Baron, fantasai, SteveZ, smfr, ChrisL
  127. # [18:17] <dsinger_> zakim, who is here?
  128. # [18:17] <Zakim> On the phone I see plinss, jdaggett, glazou, dsinger (muted), bradk, TabAtkins, sylvaing, arronei, David_Baron, fantasai, SteveZ, smfr, ChrisL
  129. # [18:17] <Zakim> On IRC I see smfr, ChrisL, szilles, dsinger_, dbaron, oyvind, RRSAgent, Zakim, glazou, sylvaing, bradk, shepazu, miketaylr, jdaggett, krijnh, arronei, jgraham, karl, fantasai,
  130. # [18:17] <Zakim> ... tabatkins, TabAtkins_, Hixie, plinss_, plinss, Bert, trackbot
  131. # [18:17] <tabatkins> jdaggett: I'll leave it to bert to respond as he is so inclined. (Since he's not on the call.)
  132. # [18:17] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Apr/0000.html
  133. # [18:18] <tabatkins> jdaggett: Next is szilles comments on character-transform.
  134. # [18:18] <sylvaing> thinks that CSS3 Fonts can't make same-origin normative; that's up to the Web Fonts WG. But it's relevant info for the spec so i like to have it there
  135. # [18:18] * Quits: dsinger_ (mobile@67.218.109.218) (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
  136. # [18:18] <tabatkins> jdaggett: I think this works; I think it's probably better.
  137. # [18:18] <tabatkins> jdaggett: Only caveat is that, the way this is worded now, if an OT font has a sub/super glyph it is used, otherwise the rendering is "as it is today".
  138. # [18:18] <tabatkins> jdaggett: I think it would be best to specify that it falls back to an auto-generated sub/super.
  139. # [18:19] <tabatkins> jdaggett: But that might have issues with nested elements.
  140. # [18:19] <tabatkins> jdaggett: The tricky thing with doing OT sub/super scripts is that they can contain other elements that aren't in a typeface.
  141. # [18:19] <tabatkins> jdaggett: They need the adjusted baseline and such, frex.
  142. # [18:19] <tabatkins> jdaggett: I think we should come back to this after experimenting, and seeing if we need to change the fallback.
  143. # [18:20] <tabatkins> jdaggett: Final issue is what to call the feature. I don't see an ideal term here.
  144. # [18:20] <tabatkins> jdaggett: I think the most accurate was "relative-script", but other people said that was awful.
  145. # [18:21] <tabatkins> szilles: I proposed character-shift and use-font-shift.
  146. # [18:21] <tabatkins> ChrisL: I'm not sure about the shift thing, it makes it sound like a baseline shift.
  147. # [18:21] <tabatkins> jdaggett: If nested elements are involved, it's more like a baseline shift.
  148. # [18:22] <tabatkins> szilles: I liked the "use-font-*", because you weren't faking it, you were using the font data.
  149. # [18:22] <tabatkins> szilles: Or alternately, a font-variant-*? Maybe font-variant-shift.
  150. # [18:22] <tabatkins> jdaggett: For now I'll put in character-transform, and we can think more about the name.
  151. # [18:22] <tabatkins> szilles: I can live with that.
  152. # [18:23] <tabatkins> smfr: I wanted to follow up on the discussion about turning on kerning everywhere.
  153. # [18:23] <tabatkins> smfr: In webkit if you go down the complex kerning-on path all the time, it significantly slows down our page performance.
  154. # [18:23] <tabatkins> jdaggett: I'm not sure that should be classified as a webkit bug. We fun on the same platform and we don't see it.
  155. # [18:23] <tabatkins> smfr: I think david said that you only turn on kerning above a certain size.
  156. # [18:23] <tabatkins> jdaggett: On Windows. On Mac we run with kerning on all the time.
  157. # [18:24] <tabatkins> smfr: Curious. I guess we can improve it somewhat, but I'd like to wait for some data that it's okay.
  158. # [18:24] <tabatkins> jdaggett: I think we left that the default was 'auto', which is defined by the UA.
  159. # [18:24] <tabatkins> fantasai: I had a comment on character-transform.
  160. # [18:24] <tabatkins> fantasai: I think, in order for nesting to work you need character-transform to not be inherited.
  161. # [18:25] <tabatkins> fantasai: Suppose I have <sub>foo<span>bar</span></sub>.
  162. # [18:25] <tabatkins> fantasai: If it's inherited, both sub and span have character-transform:sub.
  163. # [18:25] <tabatkins> fantasai: I can't tell if the span is supposed to be a further sub of the foo, or if it's suppossed to be at the same level as everything else.
  164. # [18:25] * Joins: Lachy (Lachlan@85.196.122.246)
  165. # [18:25] <tabatkins> jdaggett: That's something I should play around with.
  166. # [18:28] <Zakim> +[Apple]
  167. # [18:28] <Zakim> -dsinger
  168. # [18:28] * Joins: alexmog (alexmog@131.107.0.87)
  169. # [18:28] <tabatkins> plinss_: Next is the Selectors stuff. Anne's not on the call.
  170. # [18:29] * Joins: dsinger (dsinger@17.197.20.4)
  171. # [18:29] <tabatkins> tabatkins: I had an issue that doesn't involve anne. In Selectors, :nth-child says that the number can be omitted if a is 1 or -1. It can't always be omitted for -1.
  172. # [18:29] * dsinger zakim, [apple] has dsinger
  173. # [18:29] * Zakim +dsinger; got it
  174. # [18:29] <tabatkins> dbaron: You can omit the "1", but not the "-".
  175. # [18:29] <dbaron> fantasai, when fixing the editorial issue, the rules should end up saying that the sign cannot be omitted for -1, but the sign still can be omitted (as the previous paragraph says) for +
  176. # [18:29] <tabatkins> tabatkins: Okay, so editorial issue then, that passage is very unclear if that's what's meant.
  177. # [18:29] <tabatkins> fantasai: I can fix that.
  178. # [18:29] <fantasai> I'm just going to say the <code>1</code> can be omitted
  179. # [18:29] <dbaron> fantasai, since :nth-child(+n), :nth-child(n), and :nth-child(-n) should all be valid
  180. # [18:30] <tabatkins> fantasai: Daniel sent me a message on an editorial note and I've replied to it, but haven't prepared a response yet.
  181. # [18:30] <fantasai> s/prepared/gotten/
  182. # [18:30] <dbaron> fantasai, ok, sounds good
  183. # [18:31] <tabatkins> glazou: Since Anne's not here, I'm going to review the "serializing selectors" and post detailed comments, because otherwise it will flounder.
  184. # [18:31] <Zakim> -jdaggett
  185. # [18:31] <tabatkins> plinss_: Next topic, View Modes comments from WebAppsWG.
  186. # [18:31] <tabatkins> glazou: There was confusion last week about this.
  187. # [18:31] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
  188. # [18:31] <tabatkins> glazou: We got two requests to review 2 documents.
  189. # [18:31] <fantasai> fixed - http://dev.w3.org/csswg/selectors3/#nth-child-pseudo
  190. # [18:32] <tabatkins> glazou: First was the View Mode spec, second was the View Mode Interface spec.
  191. # [18:32] <tabatkins> glazou: This request is the first one.
  192. # [18:32] <tabatkins> glazou: I posted comments a while ago when the first draft was released.
  193. # [18:32] <tabatkins> glazou: I didn't have time to review it completely today, but it seems that all the changes I requested were done.
  194. # [18:32] <tabatkins> glazou: Mainly it clarified a bit what is a "windowed"/"floating" application, and the prose is much better than it sued to be.
  195. # [18:32] <fantasai> s/sued/used/
  196. # [18:33] <tabatkins> glazou: Other than that I have no comments.
  197. # [18:33] <tabatkins> plinss_: anyone else taken a look at this?
  198. # [18:33] <tabatkins> tabatkins: I have, and I'm reasonably happy with it now that glazou's comments have been accepted.
  199. # [18:34] <tabatkins> plinss_: So our formal response at this point is that we're happy and have no comments?
  200. # [18:34] <tabatkins> glazou: Let me reread it again in detail, but probably yes.
  201. # [18:34] <tabatkins> tabatkins: Deadline for comments is the 18th.
  202. # [18:35] <tabatkins> plinss_: Next topic, empty MQ and the DOM.
  203. # [18:35] <tabatkins> plinss_: There was some additional discussion on the list.
  204. # [18:35] <tabatkins> plinss_: Where do we stand on that?
  205. # [18:35] <tabatkins> glazou: david sent a message about that, and I and Sylvain posted followups.
  206. # [18:35] <tabatkins> glazou: IMO I think that we have 2 options.
  207. # [18:36] <tabatkins> glazou: First is to keep the syntactic rule unchanged, and change only the OM side. But that means we have to serialize the empty list to "all".
  208. # [18:36] <tabatkins> glazou: I don't really like the fact that you can't serialize back to what you got if you reparse.
  209. # [18:36] <tabatkins> glazou: Second option is to change the syntax, and allow @media with no media before the {
  210. # [18:37] <tabatkins> glazou: I spent some time thinking about it, and I think that even if it's a change, allowing @media without a media is better.
  211. # [18:37] <fantasai> I note that we discussed this twice and both times reached the same conclusion to make @media { } invalid
  212. # [18:37] <tabatkins> glazou: It's probably not in CSS2.1 right now, but it should be our goal. Otherwise it's just too complex and will lead to edge cases.
  213. # [18:37] <dbaron> I think I agree with glazou.
  214. # [18:37] <tabatkins> tabatkins: I've no objection, and I like being able to serialize back and forth cleanly.
  215. # [18:38] <tabatkins> smfr, sylvain: Like.
  216. # [18:38] <tabatkins> dbaron: FF3.6 accepts @media with no media type.
  217. # [18:38] <tabatkins> glazou: And has it mean "all"?
  218. # [18:39] <tabatkins> glazou: We just need to make sure that @media without media is a known hack, such that we will break pages if we change this.
  219. # [18:39] <tabatkins> dbaron: Yes, "all".
  220. # [18:40] <tabatkins> dbaron: In 3.6, if you have a media rule that has media types, and you dynamically remove all of them, that is equivalent to "not all"
  221. # [18:40] <tabatkins> dbaron: I suggested a possible change to MQ spec.
  222. # [18:40] * fantasai thought that was only if one of them was invalid
  223. # [18:40] <tabatkins> glazou: That's a different issue.
  224. # [18:40] <tabatkins> tabatkins: Yeah, but it's a confusing issue so that something needs to be resolved.
  225. # [18:41] <tabatkins> glazou: I think a decision is needed here. So, the proposal is to change @media in CSS3, and allow no media after the keyword, meaning "all".
  226. # [18:41] <tabatkins> plinss_: Fine with me as long as we can reconcile it with the OM.
  227. # [18:41] <tabatkins> glazou: There's nothing to reconcile. We have nothing to do on the OM side.
  228. # [18:42] <tabatkins> sylvaing: As to it being a hack, I doubt it is, since the behavior has changed for browsers across versions. It's not stable enough to set up as a good hack.
  229. # [18:42] <tabatkins> glazou: So no objections?
  230. # [18:42] <tabatkins> RESOLVED: change CSS3 so @media accepts no media after the keyword.
  231. # [18:42] <tabatkins> dbaron: Can I talk about the weird FF OM thing?
  232. # [18:42] <tabatkins> dbaron: I think that behavior is relatively logical from the spec.
  233. # [18:43] <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Apr/0592.html
  234. # [18:43] <tabatkins> dbaron: In my post I pointed out 2 statements in the spec.
  235. # [18:43] <tabatkins> If there's a query with an unknown media feature, or just a media feature value, it is ignored.
  236. # [18:43] <tabatkins> dbaron: And then if all the media are ignored, it's equivalent to "not all".
  237. # [18:44] <tabatkins> dbaron: So the weird thing is that you have to track what is ignored to see if what you have is an "all list" or a "not all list".
  238. # [18:44] <tabatkins> dbaron: So if we want to make this interoperable, we have to figure out exactly what you have to track.
  239. # [18:44] <tabatkins> dbaron: So if you have a list and you start removing a bunch of queries, what exactly happens. And is it possible to remove the queries that are ignored.
  240. # [18:45] <tabatkins> dbaron: Another way is to say that rather than the whole list is "not all", each individual ignored query is equivalent to "not all". And I think that's simpler for the OM as a whole.
  241. # [18:45] <tabatkins> ChrisL: That sounds better. What was the whole "ignored queries" thing supposed to achieve?
  242. # [18:45] <tabatkins> dbaron: It's supposed to match declarations, where if you dont' understand part of it you drop it all.
  243. # [18:45] <fantasai> ChrisL, you want @media unknown-query { body { color: red; } } to not apply
  244. # [18:46] <fantasai> Sylvain: You assume that an unknown query doesn't match.
  245. # [18:47] <tabatkins> dbaron: I'd like to hear what Anne thinks about this.
  246. # [18:47] <tabatkins> fantasai: I think he might have suggested it at some point.
  247. # [18:47] <tabatkins> dbaron: I think the "not all" for the whole list came from Anne.
  248. # [18:47] <tabatkins> sylvaing: So if you have queries that are ignored, and you serialize it, will you have "not all"s in the various places?
  249. # [18:47] <tabatkins> dbaron: I think so, yes.
  250. # [18:48] <tabatkins> plinss_: Do you want that, or do you want to preserve what was there when you reserialize?
  251. # [18:48] <tabatkins> glazou: I have to think about that.
  252. # [18:49] <tabatkins> plinss_: Otherwise you try to edit a stylesheet in an editor that happens to not understand the new declarations, you'll lose things.
  253. # [18:49] <tabatkins> fantasai: That's how declarations work now.
  254. # [18:49] <tabatkins> tabatkins: But we want to change that.
  255. # [18:49] * Joins: Me (chatzilla@70.125.40.134)
  256. # [18:49] <fantasai> s/new declarations/new media queries/
  257. # [18:49] <tabatkins> plinss_: Basically the difference between "treating it as not all" and "changing it to not all".
  258. # [18:50] * sylvaing JSCSSP is the bomb
  259. # [18:50] * glazou somebody's doing a CSS parse in JS ? ;-)
  260. # [18:50] <tabatkins> dbaron: It's different from what we've always done for properties and rules, but I think it might make sense.
  261. # [18:50] * glazou sylvaing eheh
  262. # [18:51] * sylvaing is glad we've resolved @media {} and the the new IE9 preview thus already has a bug....
  263. # [18:51] <tabatkins> plinss_: Don't have to make a decision on it right now; just throwing it out there.
  264. # [18:51] <smfr> sylvaing: webkit too!
  265. # [18:51] * sylvaing high-fives smfr. Today's bug is tomorrow's build !
  266. # [18:51] <tabatkins> plinss_: Get someone to ping Anne.
  267. # [18:52] <tabatkins> ACTION Tab: ping anne about the MQ stuff re: empty media and ignore medias.
  268. # [18:52] * trackbot noticed an ACTION. Trying to create it.
  269. # [18:52] * RRSAgent records action 1
  270. # [18:52] <trackbot> Created ACTION-227 - Ping anne about the MQ stuff re: empty media and ignore medias. [on Tab Atkins Jr. - due 2010-05-12].
  271. # [18:52] <tabatkins> plinss_: Next topic, Tab revived a decades-old display-split issue.
  272. # [18:52] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0023.html
  273. # [18:52] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0022.html
  274. # [18:52] <tabatkins> fantasai: Can we skip that for box-shadow first, since we can go to LC with them resolved?
  275. # [18:53] <tabatkins> fantasai: If we like what the wording is in what I typed, I can add it to the spec.
  276. # [18:53] <tabatkins> bradk: I like the new wording.
  277. # [18:53] <tabatkins> dbaron: How does it match existing implementations?
  278. # [18:53] <tabatkins> bradk: I don't think anyone matches the current spec fully.
  279. # [18:53] <tabatkins> sylvaing: I like it, but I'll circle back with Brian.
  280. # [18:54] * dsinger zakim, who is noisy?
  281. # [18:54] <tabatkins> smfr: What would negative value of spread do if they would cause the height/width to go below 0?
  282. # [18:54] * Zakim dsinger, listening for 10 seconds I heard sound from the following: glazou (9%), TabAtkins (52%), sylvaing (40%), fantasai (49%)
  283. # [18:54] <tabatkins> fantasai: I think at that point the shadow doesn't exist.
  284. # [18:54] * dsinger so which of you has their cell-phone too close to their other phone...?
  285. # [18:55] <tabatkins> bradk: I think still missing is a bullet point saying what the shape is if there is no spread or blur.
  286. # [18:55] * sylvaing or maybe it turns into text-replace
  287. # [18:55] <tabatkins> fantasai: The shape should be the shape fo the border box, in the draft currently.
  288. # [18:55] * glazou sylvaing only in Soviet Union, sorry Russia :-)
  289. # [18:56] <tabatkins> bradk: [issue with some of the prose concerning shape of the shadow versus where it is drawn]
  290. # [18:57] <smfr> ow my ears
  291. # [18:57] <tabatkins> bradk: I was somewhat confused when it talks about altering the shape before it even says what the shape is, and then it immediately talks about drawing.
  292. # [18:57] <tabatkins> fantasai: I can move the shape part up.
  293. # [18:58] <tabatkins> smfr: Question about negative spread, will it transform a curved corner to sharp-edged?
  294. # [18:58] <tabatkins> tabatkins: Yes.
  295. # [18:59] <tabatkins> smfr: In many cases won't negative spread just make the shadow not appear?
  296. # [18:59] <tabatkins> bradk: No, just use offset.
  297. # [18:59] <tabatkins> tabatkins: Or an inset shadow.
  298. # [18:59] <tabatkins> fantasai: A negative spread on an inset shadow will increase the size of the box.
  299. # [18:59] <tabatkins> smfr: I think we might come to weird behaviors where the shadow disconnects from the edge of the box.
  300. # [19:00] <tabatkins> fantasai: Spread changes the position of the shadow's edge.
  301. # [19:00] <tabatkins> fantasai: It doesn't make the shadow move.
  302. # [19:00] <tabatkins> smfr: The way shadows are implemented, you take the box, blit it to a bitmap with whatever color, then apply a gaussian blur.
  303. # [19:01] <tabatkins> smfr: Then spread changes the shape with some not very well-defined algorithm.
  304. # [19:01] <tabatkins> fantasai: Now the algorithm should be quite good.
  305. # [19:01] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0022.html
  306. # [19:01] <tabatkins> smfr: My problem is that spread isn't a transform on the box, it's some additional change on the box.
  307. # [19:01] <tabatkins> smfr: We can't map that to an efficient hardware implementation.
  308. # [19:01] <tabatkins> smfr: Ideally we'd want to push this to the GPU, but we can't map spread to the GPU.
  309. # [19:02] <Zakim> -bradk
  310. # [19:02] <tabatkins> tabatkins: Would a scale rather than a spread allow pushing to the GPU?
  311. # [19:02] <bradk> I got dropped
  312. # [19:02] <tabatkins> sylvaing: Yeah, a scale with the border-radius proportional allows you to easily do it in the GPU.
  313. # [19:03] <bradk> Scaling is not spread
  314. # [19:04] <tabatkins> tabatkins: Brad's the only one with sufficient experience in Photoshop et al, I think, so we just need to know if spread is *so useful* over a scale that it's worth the more difficult/slower implementation.
  315. # [19:04] <tabatkins> ChrisL: Scale and spread are different in general, but for rounded boxes they're much more similar.
  316. # [19:04] <tabatkins> sylvaing: I trust Brad to know if spread radius is more important to designers than a scale.
  317. # [19:04] <bradk> Im not on the call any more, and can't get in again
  318. # [19:04] * tabatkins I'm minuting as we talk, Brad. ^_^
  319. # [19:04] <smfr> quick, let's remove spread ;)
  320. # [19:05] <bradk> DOH!
  321. # [19:05] * sylvaing it's ok brad, it'll be back in css4
  322. # [19:05] <bradk> Scale would just be a completely different thing.
  323. # [19:05] <glazou> BTW, IE9p2 has MQ ! congrats MSFT
  324. # [19:06] <tabatkins> plinss_: So move to mailing list until next week.
  325. # [19:06] <ChrisL> I noticed that too b ut have yet to test it
  326. # [19:06] <tabatkins> fantasai: So is the question about whether people like/dislike spread, or if we want spread at all?
  327. # [19:06] <bradk> What I was starting to say is that the shape with spread applied is really no different that a spape with an extra border applied
  328. # [19:06] <tabatkins> smfr: If we have spread, we'd like it specified in a way that allows hw accelaration.
  329. # [19:06] <bradk> or an outline
  330. # [19:06] <tabatkins> smfr: Using scale would probably be the only one.
  331. # [19:07] <bradk> except that the border-radius affects the inside radius of that fake border
  332. # [19:07] <tabatkins> ChrisL: If you take the raster image, blur it, then do a threshold operation you'll get a spread.
  333. # [19:07] <tabatkins> smfr: That's two blurs, though, which is expensive.
  334. # [19:07] <bradk> If you want it to be a raster effect, then you don't get sharp corners
  335. # [19:07] <tabatkins> tabatkins: Brad's pointing out that a spread is just like increasing the border. Is that okay?
  336. # [19:08] <fantasai> The UA may | approximate the spread shape by outsetting (insetting, for inner | shadows) the shadow's straight edges by the spread radius and | increasing (decreasing, for inner shadows) and flooring at zero | the corner radii by the same amount.
  337. # [19:08] <bradk> In PhotoShop, there is a filter called "minimize" that has that sort of effect
  338. # [19:08] <tabatkins> smfr: That might be okay. Sorta confusing with inset.
  339. # [19:08] <tabatkins> fantasai: I will draw pictures for you.
  340. # [19:08] * glazou has to leave...
  341. # [19:08] <smfr> :)
  342. # [19:08] <tabatkins> fantasai: Or maybe Brad can draw pictures.
  343. # [19:08] * sylvaing only looks at images in specs..
  344. # [19:08] <bradk> For inset, it is like figuring out the shape of the content cox in the presence of padding
  345. # [19:08] <bradk> sort of
  346. # [19:09] <Zakim> -ChrisL
  347. # [19:09] <Zakim> -smfr
  348. # [19:09] <Zakim> -SteveZ
  349. # [19:09] <Zakim> -David_Baron
  350. # [19:09] <Zakim> -glazou
  351. # [19:09] <bradk> I would be happy to draw pictures
  352. # [19:09] <Zakim> -arronei
  353. # [19:09] <Zakim> -fantasai
  354. # [19:09] <glazou> sylvaing: bravo
  355. # [19:09] <Zakim> -plinss
  356. # [19:09] <Zakim> -sylvaing
  357. # [19:09] <Zakim> -[Apple]
  358. # [19:09] * tabatkins sylvain, crap, that means I have to draw more pictures.
  359. # [19:10] <bradk> I've been meaning to draw a diagram anyway...
  360. # [19:10] <fantasai> bradk: We'll need two, I think.
  361. # [19:10] <bradk> outer and inner?
  362. # [19:10] <fantasai> bradk: One for the strict definition of spread ( perpendicularly outward)
  363. # [19:10] <fantasai> bradk: (or inward)
  364. # [19:11] <bradk> OK
  365. # [19:11] <fantasai> bradk: And one for the approximation
  366. # [19:11] <fantasai> bradk: which alters the width and the radii
  367. # [19:11] <fantasai> bradk: they're not quite the same
  368. # [19:11] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  369. # [19:11] <bradk> Im not sure I understand what approximation that's different
  370. # [19:11] <fantasai> So, if you take an ellipse
  371. # [19:12] <fantasai> and you stroke it with the inner edge of the stroke being the ellipse edge
  372. # [19:12] <fantasai> the outer edge will not be an ellipse
  373. # [19:13] <fantasai> Strictly speaking, that's what you want for spread -- an offset, perpedicular to the edge, of the spread amount
  374. # [19:13] * bradk is still parsing that sentence
  375. # [19:13] <fantasai> Imagine an ellipse with arrows pointing outward from the edge
  376. # [19:13] <fantasai> like a sun, except elliptical :)
  377. # [19:13] <bradk> OK
  378. # [19:13] <fantasai> If the arrows are all the same length
  379. # [19:13] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
  380. # [19:13] <fantasai> and you draw a shape connecting their tips
  381. # [19:13] <fantasai> you will not get an ellipse
  382. # [19:14] <fantasai> You will get something that looks almost like an ellipse, but is not an ellipse
  383. # [19:14] <fantasai> in the strict mathematical sense
  384. # [19:14] <fantasai> in other words, you can't get it by defining slightly different elliptical radii
  385. # [19:14] <Zakim> disconnecting the lone participant, TabAtkins, in Style_CSS FP()12:00PM
  386. # [19:14] <Zakim> Style_CSS FP()12:00PM has ended
  387. # [19:14] <Zakim> Attendees were plinss, jdaggett, glazou, dsinger, bradk, TabAtkins, sylvaing, arronei, David_Baron, SteveZ, smfr, fantasai, ChrisL
  388. # [19:14] * Parts: smfr (smfr@17.203.14.12)
  389. # [19:14] <bradk> Umm... That is pretty much how Illustrator 88 used to do it, I think.
  390. # [19:15] <fantasai> Strictly speaking, that outward offset of the edge is what you want for a spread
  391. # [19:15] <bradk> sweeping a 1px line around the path to get a border
  392. # [19:15] <fantasai> or 5px or whatever
  393. # [19:15] <fantasai> yes
  394. # [19:15] <fantasai> But since that's not an ellipse
  395. # [19:15] <fantasai> it might be hard to calculate
  396. # [19:15] <fantasai> So that's why there's an alternate definition there
  397. # [19:16] <bradk> Do you mean because the "connect the dots" part is snot a smooth curve?
  398. # [19:16] <fantasai> that allows you to approximate the shape by altering the radii
  399. # [19:16] <fantasai> no, make it a smooth curve
  400. # [19:16] <fantasai> # arrows -> infinity
  401. # [19:16] <fantasai> It's not about the smoothness, it's about the geometry
  402. # [19:16] <fantasai> For a circle, if you do that, you will get a bigger circle
  403. # [19:16] <fantasai> but for an ellipse, you don't get an ellipse, you get something that looks like an ellipse but doesn't match its mathematical form
  404. # [19:17] <bradk> OK. I think I have seen this, come to think of it. I will play around and see if I can recreate the difference.
  405. # [19:19] <bradk> The idea of just scaling the elipse instead of offsetting the path is more palatable to the implementors?
  406. # [19:20] <bradk> I have to go. Will try tinking with clear diagrams/illustrations of the concepts tonight or soon thereafter.
  407. # [19:20] <tabatkins> Yeah.
  408. # [19:22] <bradk> OK. Bye.
  409. # [19:22] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
  410. # [19:23] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Carrier dropped, no sig$%^&&&*.....)
  411. # [19:33] * Quits: sylvaing (sylvaing@76.104.131.10) (Ping timeout)
  412. # [19:34] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
  413. # [19:34] * Quits: dsinger (dsinger@17.197.20.4) (Quit: dsinger)
  414. # [19:36] * Quits: TabAtkins_ (tabatkins@216.239.45.4) (Ping timeout)
  415. # [19:37] * Joins: TabAtkins_ (tabatkins@216.239.45.4)
  416. # [19:42] * Joins: dbaron (dbaron@63.245.220.240)
  417. # [19:46] * Quits: TabAtkins_ (tabatkins@216.239.45.4) (Ping timeout)
  418. # [19:47] * Joins: TabAtkins_ (tabatkins@216.239.45.4)
  419. # [20:03] * Quits: Me (chatzilla@70.125.40.134) (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
  420. # [20:44] * Parts: alexmog (alexmog@131.107.0.87)
  421. # [21:29] * Zakim excuses himself; his presence no longer seems to be needed
  422. # [21:29] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  423. # [22:09] * Quits: arronei (arronei@131.107.0.94) (Client exited)
  424. # [22:09] * Joins: arronei (arronei@131.107.0.98)
  425. # [23:00] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
  426. # [23:01] * Quits: szilles (chatzilla@192.150.10.200) (Ping timeout)
  427. # Session Close: Thu May 06 00:00:00 2010

The end :)