/irc-logs / w3c / #css / 2010-02-17 / end

Options:

  1. # Session Start: Wed Feb 17 00:00:00 2010
  2. # Session Ident: #css
  3. # [00:19] * Quits: dbaron (dbaron@69.140.1.234) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  4. # [01:23] * Curt`` is now known as Curt`
  5. # [03:19] * Joins: dsinger (dsinger@67.218.106.55)
  6. # [04:02] * Quits: dsinger (dsinger@67.218.106.55) (Quit: dsinger)
  7. # [04:11] * Quits: Curt` (DorkeyDear@76.243.217.170) (Quit: Leaving)
  8. # [06:09] * Joins: dsinger (dsinger@68.126.176.203)
  9. # [06:20] * Quits: TabAtkins (chatzilla@70.139.15.246) (Ping timeout)
  10. # [06:52] * Quits: Lachy (Lachlan@83.170.95.133) (Ping timeout)
  11. # [08:23] * Joins: Lachy (Lachlan@83.170.95.133)
  12. # [10:07] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: Leaving)
  13. # [10:10] * Joins: Lachy (Lachlan@83.170.95.133)
  14. # [10:17] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
  15. # [10:20] * jdaggett is now known as jdaggett-afk
  16. # [10:29] * Joins: glazou (glazou@82.247.96.19)
  17. # [10:29] * Joins: Lachy (Lachlan@88.131.66.80)
  18. # [10:29] * Quits: Lachy (Lachlan@88.131.66.80) (Client exited)
  19. # [10:29] * Joins: Lachy (Lachlan@88.131.66.80)
  20. # [10:29] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
  21. # [11:12] * Joins: jdaggett (jdaggett@118.243.226.86)
  22. # [14:27] * Quits: arronei (arronei@131.107.0.104) (Ping timeout)
  23. # [14:33] * Joins: arronei (arronei@131.107.0.72)
  24. # [14:37] * Joins: TabAtkins (chatzilla@70.139.15.246)
  25. # [14:51] * Joins: Alex_Ivaylov (alex@85.187.214.246)
  26. # [15:06] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: Leaving)
  27. # [15:07] * Joins: Lachy (Lachlan@208.100.23.169)
  28. # [15:09] * Quits: Lachy (Lachlan@208.100.23.169) (Quit: Leaving)
  29. # [15:09] * Joins: Lachy (Lachlan@88.131.66.80)
  30. # [15:40] * Joins: myakura (myakura@123.224.228.213)
  31. # [15:55] <karl> http://blog.dynatrace.com/2010/02/16/the-real-performance-overhead-of-css-expressions/
  32. # [16:00] * Joins: dbaron (dbaron@69.140.1.234)
  33. # [16:07] <anne> they're also invalid...
  34. # [16:12] * Joins: glazou (glazou@82.247.96.19)
  35. # [16:12] <glazou> Bert: ping
  36. # [16:12] <Bert> Hi Daniel, how do you feel?
  37. # [16:12] <glazou> bad
  38. # [16:12] <Bert> Hmm :-(
  39. # [16:12] <glazou> oscillating between 38 and 40 of fever
  40. # [16:13] <glazou> so I don't think I'll make the call today
  41. # [16:13] <glazou> too bad shape
  42. # [16:13] <glazou> do you think you can handle it ?
  43. # [16:13] <glazou> I sent an agenda
  44. # [16:13] <Bert> You already sent the agenda, I just have to follow it :-)
  45. # [16:14] <glazou> thanks a lot Bert and sorry for that
  46. # [16:17] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
  47. # [16:50] * Quits: dsinger (dsinger@68.126.176.203) (Quit: dsinger)
  48. # [16:51] * Quits: myakura (myakura@123.224.228.213) (Quit: Leaving...)
  49. # [16:55] * Quits: Alex_Ivaylov (alex@85.187.214.246) (Client exited)
  50. # [17:02] * Joins: Alex_Ivaylov (alex@85.187.214.246)
  51. # [17:51] * Joins: dsinger (dsinger@67.218.109.152)
  52. # [17:58] * Joins: CesarAcebal (acebal@85.152.177.64)
  53. # [17:58] * Quits: Alex_Ivaylov (alex@85.187.214.246) (Quit: Alex_Ivaylov)
  54. # [17:58] * Joins: oyvind (oyvinds@213.236.208.22)
  55. # [18:00] <dsinger> zakim, this is style
  56. # [18:00] <dsinger> invite zakim
  57. # [18:00] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  58. # [18:00] <dsinger> zakim, this is style
  59. # [18:00] <Zakim> ok, dsinger; that matches Style_CSS FP()12:00PM
  60. # [18:00] <dsinger> zakim, mute dsinger
  61. # [18:00] <Zakim> sorry, dsinger, muting is not permitted when only one person is present
  62. # [18:00] <dbaron> Zakim, who is on the phone?
  63. # [18:00] <Zakim> On the phone I see dsinger_
  64. # [18:01] * Bert thinks zakim wants people to talk to themselves. :-)
  65. # [18:01] <Zakim> +Bert
  66. # [18:01] <dsinger> zakim, do you like bus noise?
  67. # [18:01] <Zakim> I don't understand your question, dsinger.
  68. # [18:01] <dsinger> zakim, mute dsinger_
  69. # [18:01] <Zakim> dsinger_ should now be muted
  70. # [18:01] * Joins: sylvaing (sylvaing@76.104.131.10)
  71. # [18:02] <Zakim> +David_Baron
  72. # [18:02] * dsinger is on a bus, so it's a bit noisy, hence the mute
  73. # [18:02] <Zakim> +sylvaing
  74. # [18:02] * dsinger but for a change, he has a laptop so isn't using IRC on the iPhone in parallel with the cal
  75. # [18:03] <Zakim> +CesarAcebal
  76. # [18:03] * Joins: Lachy_PC (Lachy@213.236.208.22)
  77. # [18:03] * dsinger I invited zakim and told her this is style, but did not do other incantations
  78. # [18:03] * Lachy_PC is now known as anne42
  79. # [18:03] <dbaron> trackbot, start teleconference
  80. # [18:03] * trackbot is preparing a teleconference
  81. # [18:03] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  82. # [18:03] <RRSAgent> logging to http://www.w3.org/2010/02/17-CSS-irc
  83. # [18:03] <trackbot> RRSAgent, make logs member
  84. # [18:03] <RRSAgent> I have made the request, trackbot
  85. # [18:03] <trackbot> Zakim, this will be Style_CSS FP
  86. # [18:03] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
  87. # [18:03] <trackbot> Date: 17 February 2010
  88. # [18:03] <Zakim> ok, trackbot, I see Style_CSS FP()12:00PM already started
  89. # [18:04] <dbaron> RRSAgent, make logs public
  90. # [18:04] <RRSAgent> I have made the request, dbaron
  91. # [18:04] <anne42> Zakim, passcode?
  92. # [18:04] <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), anne42
  93. # [18:04] * Joins: smfr (smfr@68.183.233.11)
  94. # [18:04] <dbaron> Zakim, who is on the phone?
  95. # [18:04] <Zakim> On the phone I see dsinger_ (muted), Bert, David_Baron, sylvaing, CesarAcebal
  96. # [18:04] <Zakim> +[Microsoft]
  97. # [18:04] <smfr> sorry, can't make the call right now; will try to join later
  98. # [18:05] <arronei> zakim, Microsft is me
  99. # [18:05] <Zakim> sorry, arronei, I do not recognize a party named 'Microsft'
  100. # [18:05] <dbaron> Zakim, [Microsoft] has arronei
  101. # [18:05] <Zakim> +arronei; got it
  102. # [18:05] <Zakim> -dsinger_
  103. # [18:05] * anne42 is trying to get Skype to run :/
  104. # [18:05] <Zakim> +SteveZ
  105. # [18:05] <Zakim> +dsinger_
  106. # [18:05] <dsinger> zakim, mute dsinger_
  107. # [18:05] <Zakim> dsinger_ should now be muted
  108. # [18:06] * dsinger curses at&t and their coverage
  109. # [18:06] * Joins: szilles (chatzilla@67.180.184.118)
  110. # [18:06] <Zakim> +TabAtkins
  111. # [18:06] * dsinger run, skype, run!
  112. # [18:06] <Zakim> +??P10
  113. # [18:06] <dbaron> Zakim, ??P10 is anne
  114. # [18:06] <Zakim> +anne; got it
  115. # [18:07] <TabAtkins> Scribenick: TabAtkins
  116. # [18:07] <Zakim> +??P11
  117. # [18:07] <dbaron> Zakim, ??P11 is fantasai
  118. # [18:07] <Zakim> +fantasai; got it
  119. # [18:07] <TabAtkins> Bert: I'm chairing today, at request of glazou and plinss, as they can't attend.
  120. # [18:07] <TabAtkins> Bert: First item on agenda is testsuite. What's the status?
  121. # [18:08] <TabAtkins> fantasai: Status is, I'm working on build script and trying to fix some of the errors in html generation. Nothing else new to say.
  122. # [18:08] <TabAtkins> Bert: You're confident that will work fine shortly?
  123. # [18:08] <TabAtkins> fantasai: I hope so!
  124. # [18:08] <TabAtkins> Bert: Anything more coming up after that to be done?
  125. # [18:09] <TabAtkins> fantasai: * preserve doctypes across conversion * munging sgml comments, shouldn't do that * htaccess merging * need structured directory support * build scripts need to filter html-only vs xhtml-only * adding support for reftests
  126. # [18:10] <TabAtkins> Bert: Second topic, issue in background property grammar, raised by Yves Lafon.
  127. # [18:10] <TabAtkins> Bert: I just sent a reply.
  128. # [18:10] <Bert> http://lists.w3.org/Archives/Public/www-style/2010Jan/0248.html
  129. # [18:11] <TabAtkins> fantasai: We can add more restrictions on where this can be placed.
  130. # [18:11] <TabAtkins> fantasai: Or alternatively, if it hasn't been implemented/deployed yet, we might be able to change the syntax to not use a slash
  131. # [18:11] <TabAtkins> Bert: That sounds like a big change.
  132. # [18:11] <fantasai> something like background: url(foo.png) as 2em 2em
  133. # [18:11] <TabAtkins> Bert: There are two questions in the email from Yves.
  134. # [18:12] <TabAtkins> Bert: First, / at start isn't compatible with appendix G. I don't think that appendix applies to CSS3.
  135. # [18:12] <TabAtkins> Bert: Second is if we want to allow starting with a slash. Elika, you say we might not want that.
  136. # [18:12] <TabAtkins> Bert: Anyone have opinions on it?
  137. # [18:12] <TabAtkins> TabAtkins: I've never used it, so I can't comment on it.
  138. # [18:13] <TabAtkins> sylvaing: What does it actually do?
  139. # [18:13] <TabAtkins> Bert: It separates size from position. Behind slash, it's a size, not behind, it's a position.
  140. # [18:13] <TabAtkins> sylvaing: What happens today with it? Ignored, or what?
  141. # [18:13] <TabAtkins> Bert: It's new in B&B3, so I'm not sure what it does today.
  142. # [18:13] <TabAtkins> anne: Per css2.1 it should be ignored.
  143. # [18:14] <TabAtkins> Bert: Elika, you had a specific idea to make this better?
  144. # [18:14] <TabAtkins> fantasai: I don't know impl status, but one alternative is to change the / to "as", like "url() as <size>".
  145. # [18:14] * dbaron didn't like allowing the thing before the '/' to be omitted in the first place
  146. # [18:15] <TabAtkins> Bert: That would maybe work, but it would be a pity to take it out of CR.
  147. # [18:15] <TabAtkins> fantasai: We may need to do that anyway, for gradients.
  148. # [18:15] <TabAtkins> sylvaing: I don't like having the separator, and being able to skip what comes before it. If the slash is there, it should have something on both sides.
  149. # [18:15] <TabAtkins> Bert: So you want there to be a position every time there is a size?
  150. # [18:16] <TabAtkins> dbaron: Sorta, yeah. I've lost this argument before, but...
  151. # [18:16] * Quits: dsinger (dsinger@67.218.109.152) (Quit: dsinger)
  152. # [18:16] <TabAtkins> Bert: You have another chance to convince people. The cost is that we need to change a CR.
  153. # [18:16] <TabAtkins> sylvaing: If it's not widely implemented it's not costly, it's just editting the spec.
  154. # [18:17] <TabAtkins> fantasai: Sicne it's only been CR for a few months, if we can talk to impl and see it's not implemented, we can change it.
  155. # [18:17] <TabAtkins> Bert: We have implementors here. Has it been implemented?
  156. # [18:17] <TabAtkins> dbaron: We (mozilla) haven't done the shortcut yet. Just background-size itself, not the shorthand.
  157. # [18:17] <TabAtkins> sylvaing: We (microsoft) haven't implemented it yet.
  158. # [18:17] <dbaron> just did background-size as -moz-background-size
  159. # [18:18] <TabAtkins> Bert: 1) change slash to someething else, like a keyword 2) require a position when you specify a size, 3) leave it as is.
  160. # [18:18] <TabAtkins> Bert: I hear some support for #2. Would the size have to be in a particular place, or just *somewhere* before the slash?
  161. # [18:19] <TabAtkins> fantasai: Anywhere before the position, by current spec.
  162. # [18:19] <TabAtkins> Bert: Preferences?
  163. # [18:19] <TabAtkins> dbaron: My position is that, if you have a slash, there is a size right before it, and a position right after it.
  164. # [18:19] <TabAtkins> szilles: Is there an example elsewhere of a slash without something before it?
  165. # [18:20] <anne42> <ratio> from css3-mediaqueries requires both sides too
  166. # [18:20] <TabAtkins> dbaron: It only appears in the font shorthand, and there you need two things.
  167. # [18:20] <TabAtkins> Bert: A slash doesn't have to be a 'separator', it could just be punctuation.
  168. # [18:20] <TabAtkins> sylvaing: Are we just trying to support a pattern that no one will want to use?
  169. # [18:20] <TabAtkins> anne: Best to require a style that is consistent, so authors can read it more easily.
  170. # [18:21] <TabAtkins> sylvaing: Agreed. Dangling separators all over the place is no good.
  171. # [18:22] <TabAtkins> Bert: So I'm hearing some consensus on #2.
  172. # [18:22] <fantasai> Tab: I'm ok with requiring both, although I prefer using 'as'
  173. # [18:22] <TabAtkins> szilles: I echo Tab.
  174. # [18:22] <TabAtkins> szilles: Basically keeping / requiring a pair makes things easier to do things.
  175. # [18:22] <TabAtkins> szilles: But since in many cases you *dont'* need a position, it might be better to have size as an independent thing.
  176. # [18:23] * Joins: dsinger (dsinger@17.197.20.4)
  177. # [18:23] <TabAtkins> fantasai: Slight preference for the keyword as well.
  178. # [18:23] <Zakim> +[Apple]
  179. # [18:23] <TabAtkins> Bert: So, how to proceed? Should we have someone draw up the grammar?
  180. # [18:23] <dsinger> zakim, [apple] has dsinger
  181. # [18:23] <Zakim> +dsinger; got it
  182. # [18:23] <Zakim> -dsinger_
  183. # [18:23] * TabAtkins missed what sylvain just said, because of th ephone beeping
  184. # [18:24] <TabAtkins> fantasai: The keyword sort of directs you more towards that the number is doing something to the image.
  185. # [18:24] <fantasai> background: url(foo.png) as 100%
  186. # [18:24] <anne42> Bert, I have to leave a little early, so if items involving CSSOM could be moved forward that'd be cool
  187. # [18:24] <TabAtkins> sylvaing: As long as a / has things on both sides I'm fine, so I'm fine with either 1 or 2.
  188. # [18:24] <anne42> Bert, around 18:45
  189. # [18:24] <TabAtkins> Bert: So, consensus seems to be around the keyword, unless people have preference for a slash?
  190. # [18:25] <TabAtkins> Bert: Okay, then someone should write up the proposal for the new text/grammar.
  191. # [18:25] <TabAtkins> fantasai: I can do that.
  192. # [18:25] <fantasai> ACTION: write new text/grammar for using keyword
  193. # [18:25] * trackbot noticed an ACTION. Trying to create it.
  194. # [18:25] <trackbot> Sorry, couldn't find user - write
  195. # [18:25] * RRSAgent records action 1
  196. # [18:25] <TabAtkins> Bert: Do we need to come back to this? Or is the change simple enough that we can just accept it?
  197. # [18:25] <TabAtkins> dbaron: I think it would be useful to see what the proposal actually is.
  198. # [18:26] <TabAtkins> fantasai: Also we should check in with webkit and opera (re: implementing the / in the shorthand already).
  199. # [18:26] <TabAtkins> Bert: Next, CSSOM issues, per anne's request.
  200. # [18:26] <anne42> Bert, if I have to leave beforehand, I'd basically like people to look at the email and give some feedback, some kind of approval or disapproval at the minimum would be cool
  201. # [18:26] <TabAtkins> Bert: Property value api.
  202. # [18:27] <TabAtkins> anne: Currently all apis in cssom are string-based, so every time you query for a property you get a string back which represents the value.
  203. # [18:27] <TabAtkins> anne: the idea is that instead of a string you get a more specialized object back.
  204. # [18:27] <TabAtkins> anne: We discussed the idea briefly at tpac.
  205. # [18:27] <TabAtkins> anne: It would look like a string, but also have typed properties for the values the proeprty supports.
  206. # [18:27] <TabAtkins> anne: Frex, the background property would have a url property
  207. # [18:28] <TabAtkins> anne: Or, frex, length values, if you wanted to animate the length, you could just increase the value of the length using style.width.px or whatnot, rather than asking for a string, parsing it, changing it, sending the string back, and making the browser turn it back to a value.
  208. # [18:28] <TabAtkins> anne: Which is a lot more work than should be necessary.
  209. # [18:28] <TabAtkins> sylvaing: It makes a lot of sense in principle.
  210. # [18:29] <TabAtkins> sylvaing: It's kind of amazing that authors have to reparse css that's parsed by the browser.
  211. # [18:29] <TabAtkins> TabAtkins: Agreed, the bit of work I've done in pure css manipulation has been very annoying due to the string handling.
  212. # [18:30] <TabAtkins> sylvaing: Yeah, the javascript libraries often take away that difficulty, so we're all just spinning cycles.
  213. # [18:30] <TabAtkins> anne: The specific way I'm talking about it, there may be cross-compat issues. It will no longer do string equality, and typeof will return something new.
  214. # [18:30] <TabAtkins> anne: So we might need, say, a new accessor on the style object. style.superAwesomeTypeObject.width.px
  215. # [18:31] <TabAtkins> anne: Best is to get an experimental impl in the brwoser and see what happens.
  216. # [18:31] <TabAtkins> szilles: You said you wont' get string equality.
  217. # [18:32] <TabAtkins> anne: Like, if you get a string that's "0px", and use === to test, it would fail, becausee the object isn't a string (though it will act like one in some cases). == equality will still work.
  218. # [18:32] <TabAtkins> anne: Also, some more tpac issues - the getComputedStyle API, specifically the concept of resolved values.
  219. # [18:32] <TabAtkins> anne: Also, about how individual components get serialized to a string.
  220. # [18:33] <TabAtkins> anne: These are for the string apis. Currently everyone does something differenet. We'd like some convergence, and I'd like some feedback on exactly what should happen here.
  221. # [18:33] <TabAtkins> Bert: Current API, or new?
  222. # [18:33] <TabAtkins> anne: Current api.
  223. # [18:33] <TabAtkins> anne: Frex, if you used stylesheet value to go over the stylesheet rules, you get strings, but evereyone has a different canonical form for these string values.
  224. # [18:34] <TabAtkins> anne: I'm trying to define how these should be serialized. But since everyone does different...
  225. # [18:34] <TabAtkins> sylvaing: Yeah, even if you get convergence, you'll probably be breaking compat with older versions of each browser.
  226. # [18:34] <TabAtkins> sylvaing: I'd like a separate api on the side that can do something new so we dont' have to worry as much about painful compat issues.
  227. # [18:35] <TabAtkins> anne: This is also something that new css drafts should take into account in due course.
  228. # [18:35] <TabAtkins> anne: Frex, <image> type, like gradients, how they should be serialized to string.
  229. # [18:35] <TabAtkins> sylvaing: It would be good to document, if for no other reasons just to see how much damage would be required to converge.
  230. # [18:35] <TabAtkins> sylvaing: So we can see if possibly the property value api might be easier and cheaper for everyone.
  231. # [18:35] <TabAtkins> anne: Yes, but I think we *also* want interop on the string level.
  232. # [18:36] <TabAtkins> dbaron: I agree on string serialization.
  233. # [18:36] <TabAtkins> dbaron: I've been amking changes to our serialization where we might be returning different precisions, etc.
  234. # [18:36] <TabAtkins> dbaron: There were occasional compat problems, but they weren't horrible.
  235. # [18:36] <dbaron> s/agree on/agree we should try to converge on/
  236. # [18:36] <TabAtkins> fantasai: I think some serializations might be harder to change than others.
  237. # [18:37] <TabAtkins> fantasai: At very least, for things that are less common to be parsed, they can converge.
  238. # [18:37] <TabAtkins> sylvaing: In the property value api, the main thing is that you *don't have to* parse anymore.
  239. # [18:37] <TabAtkins> sylvaing: If you no longer have to parse, what's the reason for converging the strings except prettiness?
  240. # [18:38] <TabAtkins> anne: Authors will still depend on it.
  241. # [18:38] <TabAtkins> anne: I alos think that once we start property value api, we may not do all types at the start, just the most common, eg length, color manipulation. maybe not time and frequency.
  242. # [18:39] <TabAtkins> sylvaing: I agree. It's not hard to change, we just have a lot of corporate customers depending on existing behavior. It's why we end up with modes
  243. # [18:39] <TabAtkins> dbaron: Back to anne's point, I agree we shouldn't try and make the value api cover everything.
  244. # [18:39] <TabAtkins> dbaron: times and frequencies i'm not worried about, it's the complex data types i'm worried about.
  245. # [18:39] <TabAtkins> dbaron: A lot of times when adding new properties, i have *no idea* what data structure to use underneath.
  246. # [18:40] <TabAtkins> dbaron: Many of our new property values, even ones in css2, still don't have a sensical mapping to the value api (style level 2)
  247. # [18:40] <TabAtkins> Bert: Have you thought about that, anne?
  248. # [18:40] <dbaron> for the DOM Level 2 Style value api that we implement only for getComputedStyle
  249. # [18:40] <Zakim> +smfr
  250. # [18:40] <TabAtkins> anne: My idea was to have a base type, which is effectively a DOMString which has a cssText property.
  251. # [18:41] <TabAtkins> anne: each property would at least return the base type, serializes to a string. cssText would return whatever we agree the serialization rules should be.
  252. # [18:41] <TabAtkins> anne: For other properties, we'd have an object that inherits from this base type, and also exposed additional properties, eg color property object as r,g,b properties, maybe alpha, etc.
  253. # [18:41] <TabAtkins> anne: So you'd at least get back the string, and some would expose a little more.
  254. # [18:42] <TabAtkins> anne: And if we have properties that really need this api, we can start defining this at that point.
  255. # [18:42] <TabAtkins> anne: And hopefully CSSOM can modularize as well, so each new css spec can have a cssom part that explains how to serialize the property, and possibly value apis.
  256. # [18:43] <TabAtkins> TabAtkins: So is the idea that the DOMString object contains the current legacy browser serialization, and cssText contains the agreed on proper serialization?
  257. # [18:43] <TabAtkins> anne: No, if you call toString on the object it will just return the cssText property.
  258. # [18:44] <TabAtkins> anne: I don't think we should expose the [something something someething]. Frex, background-image would right now return just the url property, but later on when we change it, it would return a urlList property.
  259. # [18:44] <TabAtkins> Bert: I think we hear some encouragement for the approach, at least, with some caution about possible difficulties. Is this what you wanted to hear, anne?
  260. # [18:45] <TabAtkins> anne: This is a start. It would be nice to have the specific emails on www-style get input.
  261. # [18:45] <TabAtkins> sylvaing: Is there anything in your thoughts about api and design that *couldn't* be donee with javascript, so we could experiment with it?
  262. # [18:46] <TabAtkins> anne: I don't think you can extend DOMString. You may be able to change getComputedStyle itself ot return a custom object. You could probably get pretty far there.
  263. # [18:46] <TabAtkins> fantasai: As far as css specs giving serialization rules, could you post some examples of how that would look in an actual draft?
  264. # [18:47] <TabAtkins> anne: Sure, in section 7.4 it returns serialization as a generic concept. I'm hoping to deal with properties that accept multiple components to give instructions.
  265. # [18:47] <TabAtkins> anne: ie, if it's comma separated, serialize it in this way, etc.
  266. # [18:47] <TabAtkins> anne: It can be very simple. Frex, something that takes a time in seconds it serialized as a number followed by "s". Or urls serialzied as "url('" followed by literal string followed by "')".
  267. # [18:48] <TabAtkins> fantasai: What about properties that take multiples values?
  268. # [18:48] <TabAtkins> anne: For those my plan is to define that there should be at most 1 space between components, if they're comma separated the comma is adjacent to the previous value and followed by a space, etc.
  269. # [18:48] <TabAtkins> fantasai: So for most properties we'd just have to specify the order?
  270. # [18:48] <TabAtkins> anne: Yeah. And for things with multiple orders, like background position, there you'd say it is in a specified order.
  271. # [18:49] <TabAtkins> anne: Frex with margin you'd have a rule that when components can be omitted you omit as much as possible, so frex "margin: 2px 0 0 0" serializes as "2px 0 0".
  272. # [18:49] <TabAtkins> Bert: All right, so what you going to do now, anne?
  273. # [18:50] <anne42> http://dev.w3.org/csswg/cssom/
  274. # [18:50] <TabAtkins> anne: I will update the document further.
  275. # [18:50] <TabAtkins> anne: I need to finish some more details on serialization and how it maps to getComputedStyle.
  276. # [18:50] <TabAtkins> anne: Next step is to draft the proeprty value proposal, and draft a few samples like the color interface, and get feedback.
  277. # [18:50] <Zakim> -anne
  278. # [18:50] * Quits: anne42 (Lachy@213.236.208.22) (Quit: Leaving)
  279. # [18:51] <TabAtkins> Bert: Next topic, css3 values.
  280. # [18:51] * sylvaing was wondering which of -moz-fantasai or -ms-fantasai was calling in today....
  281. # [18:51] <TabAtkins> Bert: The agenda says scinot, but the emails talk about other things.
  282. # [18:51] <TabAtkins> dbaron: I haven't gotten a chance to write my proposal calc (regarding min/max) yet.
  283. # [18:51] <TabAtkins> Bert: I just sent an email with an example grammar this morning.
  284. # [18:51] <TabAtkins> Bert: We may want to talk about that later, once people have a chance to read it.
  285. # [18:52] <TabAtkins> Bert: So, back to scinot.
  286. # [18:52] <TabAtkins> Bert: Any actions from that last week?
  287. # [18:52] <TabAtkins> sylvaing: ONly concerns, which I introduced, was that it would become a new CSS hack to separate browsers.
  288. # [18:52] <TabAtkins> sylvaing: But it turns out that IE already does this, so the hack has been out there already.
  289. # [18:52] <TabAtkins> Bert: Explain the hack?
  290. # [18:53] <TabAtkins> sylvaing: Once a new browser supports scinot, you can use it to exclude older browsers from parsing that rule.
  291. # [18:53] <TabAtkins> sylvaing: I don't think it's a serious issue, since Selectors already allows that, and Selectors-based ones are more powerful anyway.
  292. # [18:53] <TabAtkins> sylvaing: So I don't think scinot is much of a hack in practice anyway.
  293. # [18:53] <TabAtkins> sylvaing: But given that the hack is *already out there* in IE if you want it, I think the issue is moot.
  294. # [18:54] <TabAtkins> Bert: I understand for the selectors hack, but what's this about IE notation already doing the hack?
  295. # [18:54] <TabAtkins> sylvaing: in IE, you can already specify "width:1e2px", and it will work in IE but not other browsers.
  296. # [18:54] <TabAtkins> sylvaing: So the argumeent that we shouldn't introduce this notation because it would introduce this hack is bogus, since it's already supported.
  297. # [18:55] <TabAtkins> Bert: In fact it seems to make the hack impossible to use, since legacy browsers already use it.
  298. # [18:55] <TabAtkins> Bert: Is anyone going to write up examples?
  299. # [18:55] <TabAtkins> szilles: I think Chris got tasked with some of that; this is based just on reading the minutes.
  300. # [18:56] <TabAtkins> Bert: So no new information?
  301. # [18:56] <TabAtkins> TabAtkins: Apart from the knowledge about the ie hack, no. We might want to ping Chris about it.
  302. # [18:58] <TabAtkins> sylvaing: What are the details of exactly how SVG allows it?
  303. # [18:58] <TabAtkins> TabAtkins: It was explained on the list; I forget the exact details, but some types of values allow it, but not all.
  304. # [18:58] <TabAtkins> sylvaing: So like Hakon's talking about allowing it when necessary?
  305. # [18:58] <TabAtkins> TabAtkins: Not quite. it's not property-specific, but rather value specific.
  306. # [18:59] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
  307. # [18:59] <TabAtkins> TabAtkins: Also, HTML5 and JS all rely on the ecmascript serialization, which uses scinot. So we could align with HTML as well.
  308. # [18:59] <TabAtkins> Bert: All right, so leet's move to a simpler topic for now. Image fit?
  309. # [19:00] <TabAtkins> fantasai: I want to write up a response to the most recent image-fit email. Some things I agreed with, some I didn't.
  310. # [19:00] <Bert> http://lists.w3.org/Archives/Public/www-style/2010Jan/0476.html
  311. # [19:00] <TabAtkins> Bert: Ok, let's just look at the message detailed in the agenda.
  312. # [19:00] <shepazu> (I think image-fit would be a good topic for discussion in the FXTF)
  313. # [19:01] <TabAtkins> bert: 4 issues in the email.
  314. # [19:01] <TabAtkins> Bert: When dealing with overflow on replaced elements.
  315. # [19:01] <TabAtkins> fantasai: I think last time I discussed this with Molly, we suggested always clipping.
  316. # [19:01] <TabAtkins> Bert: That's different from what's in the email, which suggests overflowing and letting overflow apply. You're suggesting always clip?
  317. # [19:02] <TabAtkins> szilles: That seems dangerous if you're losing content. Best might be scrollbars; some kind of warning tha tyou're not seeing all the image.
  318. # [19:02] <TabAtkins> Bert: I do see examples in practice of people using a wrapper to force clipping the image.
  319. # [19:02] <TabAtkins> TabAtkins: I've done precisely that.
  320. # [19:02] <TabAtkins> fantasai: [something about default behavior]
  321. # [19:02] <TabAtkins> fantasai: contain is no scrolling, just a cover.
  322. # [19:03] <TabAtkins> Bert: As soon as you use that, you're assured you will get clipping. That's sort of explicit?
  323. # [19:03] <TabAtkins> fantasai: And then image-position lets you specify exactly which part gets shown. I don't htink it makes sense to combine that with scrollbars.
  324. # [19:03] * Joins: Skaterband1 (Skaterband@4.171.159.55)
  325. # [19:03] <Skaterband1> hi all
  326. # [19:03] <TabAtkins> szilles: As long as it's clear that it's a conscious decision to force the clipping.
  327. # [19:04] <TabAtkins> Bert: I like this idea, but are there any other ideas?
  328. # [19:04] <Skaterband1> i was needing some irc help
  329. # [19:04] <TabAtkins> Bert: No dissent. We may need to come back to this topic, since there are more issues anyway.
  330. # [19:04] <TabAtkins> Bert: I suggest we continue on image-fit next week. anything else to be said?
  331. # [19:04] <Skaterband1> im trying to build a multi room irc
  332. # [19:05] <TabAtkins> dsinger: I sent an email to peter/glazou on hosting the meeting, but i haven't heard anything back from them. who should I send it to?
  333. # [19:05] <TabAtkins> bert: Send it to me.
  334. # [19:05] * Parts: Skaterband1 (Skaterband@4.171.159.55)
  335. # [19:05] * Joins: Skaterband1 (Skaterband@4.171.159.55)
  336. # [19:05] <Skaterband1> hi
  337. # [19:05] <Zakim> -TabAtkins
  338. # [19:05] <Zakim> -SteveZ
  339. # [19:05] <Zakim> -sylvaing
  340. # [19:05] <Zakim> -[Microsoft]
  341. # [19:05] <Zakim> -smfr
  342. # [19:05] <Zakim> -David_Baron
  343. # [19:05] <Zakim> -CesarAcebal
  344. # [19:05] * Parts: Skaterband1 (Skaterband@4.171.159.55)
  345. # [19:05] <Zakim> -Bert
  346. # [19:06] <Zakim> -[Apple]
  347. # [19:06] <Zakim> Style_CSS FP()12:00PM has ended
  348. # [19:06] <Zakim> Attendees were dsinger_, Bert, David_Baron, sylvaing, CesarAcebal, arronei, SteveZ, TabAtkins, anne, fantasai, dsinger, smfr
  349. # [19:06] * Quits: smfr (smfr@68.183.233.11) (Quit: smfr)
  350. # [19:17] * Quits: CesarAcebal (acebal@85.152.177.64) (Quit: CesarAcebal)
  351. # [19:17] * Quits: dsinger (dsinger@17.197.20.4) (Quit: dsinger)
  352. # [19:18] * Joins: CesarAcebal (acebal@85.152.177.64)
  353. # [19:19] * Quits: sylvaing (sylvaing@76.104.131.10) (Ping timeout)
  354. # [19:30] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
  355. # [19:52] * Joins: sylvaing (sylvaing@131.107.0.86)
  356. # [19:53] * Quits: sylvaing (sylvaing@131.107.0.86) (Quit: sylvaing)
  357. # [20:46] * Zakim excuses himself; his presence no longer seems to be needed
  358. # [20:46] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  359. # [21:07] * Parts: CesarAcebal (acebal@85.152.177.64)
  360. # [21:12] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  361. # [21:13] * Joins: Lachy (Lachlan@88.131.66.80)
  362. # [21:13] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  363. # [21:41] * Joins: Lachy (Lachlan@81.170.212.11)
  364. # [21:42] * Quits: Lachy (Lachlan@81.170.212.11) (Quit: Leaving)
  365. # [21:42] * Joins: Lachy (Lachlan@83.170.95.133)
  366. # [23:25] * Quits: jdaggett (jdaggett@118.243.226.86) (Quit: jdaggett)
  367. # [23:25] <fantasai> Bert: is the www-style moderation queue clear? someone mentioned emails being stuck in the queue
  368. # [23:26] * Quits: dbaron (dbaron@69.140.1.234) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  369. # [23:27] <Bert> I'll take a look...
  370. # [23:30] <Bert> There is Leif Arne Storset's message, but he already quoted it in his mail from yesterday.
  371. # [23:33] <Bert> Some other messages that look more like the senders forgot to subscribe...
  372. # [23:33] * Quits: szilles (chatzilla@67.180.184.118) (Ping timeout)
  373. # Session Close: Thu Feb 18 00:00:00 2010

The end :)