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

Options:

  1. # Session Start: Wed Mar 03 00:00:00 2010
  2. # Session Ident: #css
  3. # [00:37] * Quits: sylvaing (sylvaing@131.107.0.105) (Ping timeout)
  4. # [01:35] * Joins: sylvaing (sylvaing@131.107.0.75)
  5. # [01:59] * Quits: sylvaing (sylvaing@131.107.0.75) (Ping timeout)
  6. # [03:08] * Quits: Lachy (Lachlan@83.170.95.133) (Ping timeout)
  7. # [03:22] * Joins: Lachy (Lachlan@81.170.212.11)
  8. # [03:25] * Quits: Lachy (Lachlan@81.170.212.11) (Ping timeout)
  9. # [03:25] * Joins: Lachy (Lachlan@83.170.95.133)
  10. # [04:40] * Joins: sylvaing (sylvaing@76.104.131.10)
  11. # [04:50] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  12. # [04:53] * Quits: Curt` (DorkeyDear@76.243.210.82) (Quit: Leaving)
  13. # [05:05] * Quits: karl (karlcow@128.30.54.58) (Client exited)
  14. # [05:12] * Quits: sylvaing (sylvaing@76.104.131.10) (Ping timeout)
  15. # [05:53] * Joins: karl (karlcow@128.30.54.58)
  16. # [06:11] * Joins: dbaron (dbaron@98.234.51.190)
  17. # [08:18] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: Leaving)
  18. # [08:18] * Joins: Lachy (Lachlan@83.170.95.133)
  19. # [08:27] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  20. # [08:56] * Joins: Doof (mstensho@213.236.208.22)
  21. # [09:40] * Joins: glazou (daniel@80.118.184.70)
  22. # [09:40] <glazou> fantasai: ping
  23. # [09:52] <glazou> bbl
  24. # [09:52] * Quits: glazou (daniel@80.118.184.70) (Quit: bbl)
  25. # [10:17] * Quits: jdaggett_afk (jdaggett@202.221.217.73) (Quit: jdaggett_afk)
  26. # [10:32] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
  27. # [10:34] * Joins: glazou (daniel@80.118.184.70)
  28. # [10:34] <glazou> Bert: yt ?
  29. # [10:47] * Joins: Lachy (Lachlan@88.131.66.80)
  30. # [11:13] <Bert> Hi glazou. sorry, was away from my machine.
  31. # [11:13] <glazou> no problem :-)
  32. # [11:13] <glazou> hi
  33. # [11:13] <glazou> I have a problem to show you
  34. # [11:14] <Bert> What kind of?
  35. # [11:14] <glazou> CSS 2.1 says all @import should occur before all other rules except @charset
  36. # [11:15] <glazou> but Namespaces module also says @namespace must occur only after @import rules
  37. # [11:15] <glazou> so if we have the following
  38. # [11:15] <glazou> @namespace url(...);
  39. # [11:15] <glazou> @import foo.html;
  40. # [11:15] <glazou> which one is invalid ?
  41. # [11:15] <glazou> :-)
  42. # [11:15] <anne> the first
  43. # [11:16] <anne> the second is dropped
  44. # [11:16] <glazou> is asked "invalid"
  45. # [11:16] <glazou> I asked
  46. # [11:16] <glazou> you say 1st is valid and 2nd invalid
  47. # [11:16] <anne> and for @namespace url(...); @import foo; @namespace x url(...); only the second is dropped
  48. # [11:16] <glazou> right ?
  49. # [11:16] <anne> yes
  50. # [11:17] <anne> because in your example there is no @import rule
  51. # [11:17] <Bert> Ah, the "which" was never a question when we designed that. :-) It's invalid, that's all. But I guess you want to "save" as much of the invalid style sheet as possible...
  52. # [11:17] <anne> at the object level
  53. # [11:17] <glazou> ok validity at parse time takes precedence over prose
  54. # [11:17] <anne> annoyingly CSS is mostly described in terms of syntax so this distinction is not quite clear
  55. # [11:17] <glazou> I wondered if a clarification or an example is not needed here
  56. # [11:19] <glazou> in the namespaces module for instance
  57. # [11:20] <Bert> Considering that most parsers parse from start to end and probably already did a bit of work when they found the ";" after @namespace, it's probably best to keep the @namespace and drop the @import.
  58. # [11:21] <glazou> yes, it would require lookahead or lookback otherwise
  59. # [11:21] <glazou> ok just wanted to make sure we're all on same track here
  60. # [11:21] <glazou> I asked because I am implementing a css parser right now
  61. # [11:22] <glazou> preserving unknown rules
  62. # [11:22] <glazou> comments
  63. # [11:22] <glazou> and even whitespaces on demand
  64. # [11:22] <Bert> @namespace doesn't exist in CSS 2.1, so the most obvious place for a clarification would be the Namespace module.
  65. # [11:23] <glazou> well
  66. # [11:23] <Bert> I did some error-recovery experiments last week, using Yacc. But I want to try in Java next, because Yacc/Lex isn't very handy with UTF-8 input...
  67. # [11:23] <glazou> could also be a note in css 2.1 saying that validity in a sheet is verified at parse time, in chronological order of the rules
  68. # [11:23] <anne> I'm not at all convinced we can even discuss that it is not clear, but I'm willing to add examples
  69. # [11:24] <glazou> anne: agreed, the prose is clear ; but the way a css parser should be implemented is not...
  70. # [11:25] <Bert> I don't know yet if it is already clear. Have to look at the text first. Just saying *if* we need a clarification about @namespace and @import, I'd expect it in Namespaces.
  71. # [11:25] <anne> I'm not sure about that either, though I will conceed that CSS parsing is way more complicated than it should've been
  72. # [11:25] <anne> but that's not my fault
  73. # [11:25] <glazou> nobody said it's your fault
  74. # [11:25] <glazou> :)
  75. # [11:26] <glazou> anyway, Bert, anne, I wanted to raise the point since I hit the question myself implementing my parser
  76. # [11:27] <Bert> What's complicated is just the attempts to recover from errors by second-guessing the author that we bolted on afterwards. It's very easy to know if something is right or wrong.
  77. # [11:27] <anne> neh, what's complicated is that you can escape ASCII syntax for no reason
  78. # [11:27] <anne> e.g. the enormous amounts of ways you can write url() is just disturbing
  79. # [11:27] <anne> or any given property name for that matter
  80. # [11:29] <anne> the reason the error recovery rules are complex is because they are bolt-on on top of the grammar
  81. # [11:30] <glazou> absolutely
  82. # [12:55] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  83. # [12:57] * Joins: Lachy (Lachlan@88.131.66.80)
  84. # [13:53] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  85. # [14:40] * Disconnected
  86. # [14:41] * Attempting to rejoin channel #css
  87. # [14:41] * Rejoined channel #css
  88. # [15:06] * Joins: jdaggett (jdaggett@118.243.226.86)
  89. # [15:06] * jdaggett is now known as jdaggett_zzz
  90. # [15:33] * Quits: glazou (daniel@80.118.184.70) (Ping timeout)
  91. # [16:12] * Joins: mollydotcom (mollyh@68.231.162.204)
  92. # [16:16] <mollydotcom> hi all, gonna hang out but can't make call, my friend Dale is in ICU after brain surgery, not doing so well, so I'm distracted but here if needed.
  93. # [16:20] * Joins: sylvaing (sylvaing@76.104.131.10)
  94. # [16:36] * Joins: lstorset (lstorset@213.236.208.22)
  95. # [17:23] * mollydotcom says hello to all
  96. # [17:25] <TabAtkins> Yo, molly!
  97. # [17:28] <mollydotcom> Hey TabAtkins, how goes?
  98. # [17:28] <anne> have fun goes
  99. # [17:28] * anne has to go
  100. # [17:28] <mollydotcom> bye Anne
  101. # [17:28] <TabAtkins> Frustratingly. Configuring SSL is fraught with peril!
  102. # [17:29] <lstorset> Hi Molly!
  103. # [17:29] <mollydotcom> hey lstorset, so happy you're here
  104. # [17:29] <lstorset> Thanks
  105. # [17:29] <mollydotcom> have you been introduced around?
  106. # [17:29] <lstorset> No, not yet
  107. # [17:30] <lstorset> But I hear there are a lot of great people here
  108. # [17:30] * mollydotcom wants to welcome lstorset (leif) from Opera
  109. # [17:30] <TabAtkins> Ah, hey Leif!
  110. # [17:30] <TabAtkins> btw, how do you pronounce that?
  111. # [17:30] <lstorset> Hello Tab!
  112. # [17:30] <lstorset> like "Life"
  113. # [17:31] <TabAtkins> Thought so.
  114. # [17:31] <lstorset> I was the butt of many, many jokes during my year in California :)
  115. # [17:31] <lstorset> "Life sucks"
  116. # [17:31] <mollydotcom> everyone is the butt of many joked in California. Unless he or she isn't doing a proper job ;)
  117. # [17:31] <lstorset> so true :)
  118. # [17:31] <mollydotcom> oh! that's not funny
  119. # [17:31] <mollydotcom> lol
  120. # [17:32] <lstorset> what do you do, TabAtkins? the member page just says "invited expert"
  121. # [17:33] <TabAtkins> At the moment I'm finishing out the week working as webmaster for my company. On the 22nd I'll be working with Google, hopefully on the Chrome team.
  122. # [17:33] <lstorset> cool, congratulations!
  123. # [17:33] <TabAtkins> ^_^
  124. # [17:34] <mollydotcom> Chrome rocks. But not as much as Opera :P
  125. # [17:34] <lstorset> do you have browser wars every week in this group? :P
  126. # [17:34] <mollydotcom> hahahaha
  127. # [17:35] <mollydotcom> folks, I ask of you, do we have browser wars in this group and if so, how often?
  128. # [17:35] <mollydotcom> TBH, Leif, this is a great group of passionate people
  129. # [17:36] <mollydotcom> we don't have wars. We have intellectual disagreements.
  130. # [17:36] <TabAtkins> We're all a big happy family.
  131. # [17:36] <lstorset> Glad to hear it :)
  132. # [17:36] <mollydotcom> in our own dysfunctional way ;)
  133. # [17:36] <TabAtkins> Dysfunctional? Surely you jest, Molly!
  134. # [17:37] * mollydotcom jest? Checks halo integrity
  135. # [17:42] * Joins: bradk (bradk@67.188.133.45)
  136. # [17:50] * Joins: glazou (glazou@82.247.96.19)
  137. # [17:51] * Parts: glazou (glazou@82.247.96.19)
  138. # [17:57] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  139. # [17:57] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  140. # [17:57] <RRSAgent> logging to http://www.w3.org/2010/03/03-CSS-irc
  141. # [17:57] <plinss> rrsagent, make logs public
  142. # [17:57] <RRSAgent> I have made the request, plinss
  143. # [17:57] <plinss> zakim, this will be style
  144. # [17:57] <Zakim> ok, plinss; I see Style_CSS FP()12:00PM scheduled to start in 4 minutes
  145. # [17:58] <Zakim> Style_CSS FP()12:00PM has now started
  146. # [17:58] <Zakim> +plinss
  147. # [17:59] <Zakim> + +0472369aaaa
  148. # [17:59] <plinss> zakim, aaaa is lstorset
  149. # [17:59] <Zakim> +lstorset; got it
  150. # [17:59] <Zakim> +sylvaing
  151. # [18:00] * Joins: smfr (smfr@68.183.233.11)
  152. # [18:00] * Joins: dethbakin (dethbakin@98.234.211.150)
  153. # [18:00] <mollydotcom> I'm here but no phone or Skype access
  154. # [18:00] <mollydotcom> sorry, limited technology
  155. # [18:00] <Zakim> + +1.253.307.aabb
  156. # [18:00] * Joins: oyvind (oyvinds@213.236.208.22)
  157. # [18:01] <Zakim> +dethbakin
  158. # [18:02] <Zakim> +smfr
  159. # [18:02] <Zakim> +bradk
  160. # [18:02] * Joins: glazou (glazou@82.247.96.19)
  161. # [18:02] <glazou> hi there
  162. # [18:02] <smfr> morning
  163. # [18:02] <bradk> hello
  164. # [18:02] <Zakim> +glazou
  165. # [18:03] <Zakim> +TabAtkins
  166. # [18:03] * Joins: howcome (howcome@80.203.19.236)
  167. # [18:03] <Zakim> +Hakon_Lie
  168. # [18:04] <Zakim> +Bert
  169. # [18:04] * mollydotcom will be cheering from the IRC benches
  170. # [18:07] <TabAtkins> ScribeNick: TabAtkins
  171. # [18:08] <Zakim> +??P3
  172. # [18:08] <TabAtkins> plinss: Anything else on the agenda?
  173. # [18:08] <TabAtkins> sylvaing: I submitted comments from a colleague in Japan for CSS3 Lists; not sure if that spec is dormant or what.
  174. # [18:08] <glazou> Zakim, mute me
  175. # [18:08] <Zakim> glazou should now be muted
  176. # [18:09] <TabAtkins> sylvaing: They wanted to know what the status was of that spec.
  177. # [18:09] <TabAtkins> fantasai: Lists doesn't have an active editor right now.
  178. # [18:09] <TabAtkins> fantasai: There's a lot of corrections that need to go into there. I made some of them that were minor.
  179. # [18:10] <TabAtkins> sylvaing: I guess the important thing is to find someone who can assert that the suggested changes are correct.
  180. # [18:10] * Joins: ChrisL (ChrisL@128.30.52.169)
  181. # [18:10] <glazou> hi ChrisL, wb, just got your email
  182. # [18:10] <TabAtkins> fantasai: As for correcting obviously wrong things, we can probably just do that.
  183. # [18:11] <TabAtkins> fantasai: Lists probably needs a review in general, but if we just get a patch we can just check those changes into the ED.
  184. # [18:11] <TabAtkins> plinss: Image-fit talk, revisiting the auto discussion
  185. # [18:11] <glazou> Norwegian slackers :-)
  186. # [18:12] <Zakim> +[IPcaller]
  187. # [18:12] <TabAtkins> howcome: I discussed with our implementors, and they're clear that they need 'auto'.
  188. # [18:12] <TabAtkins> howcome: I've brought Leif in today. He's been implementing this stuff.
  189. # [18:13] <TabAtkins> howcome: We'd like to have an auto value. We don't need to say exactly what it does (refer to past behaviors), but just establish the borders and let the content do what it wants.
  190. # [18:13] <TabAtkins> howcome: And then let 'fill' be very explicit that it fills the whole rectangle for all media types.
  191. # [18:13] <Zakim> +SteveZ
  192. # [18:13] <Zakim> +[Mozilla]
  193. # [18:13] * Joins: dbaron (dbaron@63.245.220.240)
  194. # [18:14] <TabAtkins> TabAtkins: Insofar as we need magic values based on media type, I like this.
  195. # [18:14] * dbaron Zakim, [Mozilla] has dbaron
  196. # [18:14] * Zakim +dbaron; got it
  197. # [18:14] <TabAtkins> Bert: Not all types can scale. a java applet, frex, can't scale in two separate dimensions.
  198. # [18:14] * dbaron RRSAgent, pointer?
  199. # [18:14] * RRSAgent See http://www.w3.org/2010/03/03-CSS-irc#T17-12-57
  200. # [18:14] <TabAtkins> howcome: True, but for many media types like video it can do so.
  201. # [18:15] <TabAtkins> TabAtkins: What would we specify happens for media types that can't scale like that?
  202. # [18:15] <TabAtkins> howcome: They should fill insofar as it's possible to do.
  203. # [18:15] * sylvaing -ms-moz-webkit-o-css:auto; should take care of it
  204. # [18:15] <TabAtkins> ChrisL: Suppose you have something that can only scale proportionately. Do you make it act like cover or contain?
  205. # [18:16] * glazou sylvaing lol
  206. # [18:16] <Zakim> - +1.253.307.aabb
  207. # [18:16] <TabAtkins> howcome: I don't think we *can* specify all possible details. Frex, widescreen video sometimes has the edges scaled differently from the center.
  208. # [18:17] <TabAtkins> TabAtkins: So if they *could* scale properly, they must, but if they couldn't, it's undefined?
  209. # [18:17] * Joins: szilles (chatzilla@71.94.81.196)
  210. # [18:17] <TabAtkins> Bert: How is this different from auto?
  211. # [18:17] <TabAtkins> howcome: It would establish a rectangle, and say the content is free to do whatever it wants inside of there.
  212. # [18:18] * TabAtkins I think my line dropped.
  213. # [18:18] <Zakim> -TabAtkins
  214. # [18:18] * Quits: howcome (howcome@80.203.19.236) (Ping timeout)
  215. # [18:18] <Zakim> +TabAtkins
  216. # [18:19] <glazou> wb TabAtkins
  217. # [18:19] <Zakim> -smfr
  218. # [18:19] <smfr> my turn
  219. # [18:19] <Zakim> +[Microsoft]
  220. # [18:19] <Zakim> +smfr
  221. # [18:20] <TabAtkins> TabAtkins: Given that we're allowing media to do whatever it wants if it can't fill properly, what's the difference with auto?
  222. # [18:21] <TabAtkins> howcome: There's a convention that you change the aspect ratio for images, but not videos.
  223. # [18:21] <TabAtkins> dbaron: 1) Why should this be a value rather than selectors in the UA style sheet? (2) I think some of the object behavior in SVG is just bugs, and I don't think that content depends on it
  224. # [18:22] <Zakim> -SteveZ
  225. # [18:22] <TabAtkins> howcome: You could do UA stylesheet and specify different behavior for elements, but can't do this for differing media types.
  226. # [18:22] <TabAtkins> dbaron: I'd almost rather see Selectors rather than a weird value, even if it's just for UA and not exposed to the web.
  227. # [18:23] <TabAtkins> dbaron: It sounds like auto is 'whatever you want it to be', not 'what you would expect'. We should define it.
  228. # [18:23] <Zakim> +SteveZ
  229. # [18:23] <TabAtkins> plinss: We have some auto values that *do* mean 'do whatever the UA wants to do'.
  230. # [18:23] <TabAtkins> dbaron: Example?
  231. # [18:23] <TabAtkins> plinss: (goes to look)
  232. # [18:23] <lstorset> 'auto' is used in 'overflow' as 'UA decides'
  233. # [18:23] <dbaron> lstorset, no
  234. # [18:23] <glazou> Zakim, unmute me
  235. # [18:23] <Zakim> glazou should no longer be muted
  236. # [18:23] <TabAtkins> howcome: Scaling video is still a big deal. It doesn't depend on the media type, but on the processor.
  237. # [18:24] <TabAtkins> ChrisL: Yeah, you want to treat video differently on lower-powered platforms.
  238. # [18:24] <Zakim> -SteveZ
  239. # [18:24] <TabAtkins> Bert: You may also want to, say, rotate the video. That also might not work on low-powered devices.
  240. # [18:24] <Zakim> +SteveZ
  241. # [18:24] <TabAtkins> Bert: Look at communication between image and document. image gives actual width and height, document gives desired width and height.
  242. # [18:25] <TabAtkins> Bert: That's all. You'll need a third value to pass around to say 'auto'.
  243. # [18:25] <TabAtkins> howcome: Yeah, you'll need a flag to be passed. We think it's useful enough to do.
  244. # [18:25] <TabAtkins> fantasai: Who's going to modify the plugin UI?
  245. # [18:25] <TabAtkins> howcome: I don't think plugins are relevant here; we're moving away from them.
  246. # [18:25] <TabAtkins> szilles: I beg to differ!
  247. # [18:25] <dbaron> s/plugin UI/plugin API/
  248. # [18:26] <TabAtkins> Bert: Steve is right; we dont' know the formats that will be used in the future, and we designed it so that it can be extended.
  249. # [18:26] * sylvaing apart from all the content out there, who needs plugins, really ?
  250. # [18:26] * ChrisL "legacy flash content"
  251. # [18:26] <glazou> who's speaking now ?
  252. # [18:26] <sylvaing> leif
  253. # [18:26] * ChrisL leif
  254. # [18:26] <glazou> ok
  255. # [18:26] <TabAtkins> Leif: About the motivation for auto, it was inserted so we could be backwards-compatible and still maintain the meaning of fill.
  256. # [18:26] <TabAtkins> fantasai: I don't have a *problem* with auto as long as the model between the document and the media doesn't change.
  257. # [18:27] * Joins: arronei (arronei@131.107.0.104)
  258. # [18:27] <TabAtkins> fantasai: So if auto is just implemented by varying on the content-type and aliasing to different image-fit values, that would be fine.
  259. # [18:27] <TabAtkins> fantasai: Frex, video 'auto' would act like 'contain'.
  260. # [18:27] <TabAtkins> sylvaing: I agree. 'auto' should map to one of the existing.
  261. # [18:27] <sylvaing> ...values
  262. # [18:27] <TabAtkins> fantasai: I'm not happy with 'auto' meaning 'tell the content something special'.
  263. # [18:28] <TabAtkins> howcome: Would you like to describe in the spec which medias map to which values?
  264. # [18:28] <TabAtkins> fantasai: If we're going to do this, then yes, we want it in the spec. We want interop.
  265. # [18:28] <TabAtkins> fantasai: Of course, if you have a new video plugin, the UA may not know that it's a video.
  266. # [18:28] * glazou feels Bert is lost
  267. # [18:29] <TabAtkins> howcome: Right, so plugins would be considered a media type.
  268. # [18:29] * Bert thinks about content-type: application/plugin :-)
  269. # [18:29] <TabAtkins> ChrisL: What would it map to for SVG?
  270. # [18:30] <TabAtkins> ChrisL: I'm not happy with something that says "every piece of svg in html now breaks".
  271. # [18:30] <TabAtkins> fantasai: SVG would work the same as everything else. We'd draw a box based on image-fit, and then SVG just does whatever it wants.
  272. # [18:30] * sylvaing glazou, or does Bert think we're all lost :)
  273. # [18:30] <TabAtkins> fantasai: So for SVG you probably want auto to act like fill.
  274. # [18:30] <glazou> bradk: yt?
  275. # [18:30] <TabAtkins> fantasai: And then SVG can cover/contain/scale itself based on that box depending on its own attributes.
  276. # [18:31] <TabAtkins> fantasai: We should probably be able to distinguish between video and images.
  277. # [18:31] <bradk> ??
  278. # [18:31] <TabAtkins> ChrisL: Animated GIF, like video but can scale?
  279. # [18:31] <TabAtkins> szilles: Problem with table is that it gets fixed at some point.
  280. # [18:31] <glazou> bradk: just answered your quesiton in www-style
  281. # [18:31] <TabAtkins> fantasai: Yeah, but we dont' get top-level types very often.
  282. # [18:32] <TabAtkins> szilles: Plugins are an extension mechanism, though, and I don't think there's a useful way to standardize this.
  283. # [18:32] <TabAtkins> fantasai: I think do the same as SVG - treat 'auto' as 'fill', and then tell the plugin 'Hey, render yourself in this nice box'.
  284. # [18:33] <TabAtkins> fantasai: Seems the only thing that changes is that video sizes as contain, everything else acts like fill.
  285. # [18:33] <TabAtkins> fantasai: Was there any other change?
  286. # [18:34] <TabAtkins> TabAtkins: The third one was that SVG should be 'none', and keep its own intrinsic dimensions.
  287. # [18:34] <TabAtkins> fantasai: I think that if, in CSS, we treat it as fill and just hand it the resulting viewport box, it can figure out what to scale for itself.
  288. # [18:34] <TabAtkins> ChrisL: It's fine to have different values in CSS to give SVG new viewports; SVG already knows how to scale itself.
  289. # [18:35] <TabAtkins> ChrisL: It's also fine to have CSS tell SVG specifically how to scale, but I dont' want it to happen by default.
  290. # [18:35] <TabAtkins> fantasai: So, the way image-fit imposes on SVG is not by telling SVG how to scale; it just asks SVG for its intrinsic size and then hands it a viewport.
  291. # [18:36] <TabAtkins> TabAtkins: So the *only* difference with auto is that video will scale as contain, everything else scales as fill?
  292. # [18:36] <TabAtkins> fantasai: I think so, yeah.
  293. # [18:36] <TabAtkins> ChrisL: I see the value there. It's not wide-open anymore; much more implementable and testable.
  294. # [18:37] <TabAtkins> szilles: Can anyone precisely answer whether the video/everything else is the only relevant distinction for auto?
  295. # [18:37] <TabAtkins> howcome: Leif appears to be gone?
  296. # [18:37] <lstorset> can you hear me?
  297. # [18:37] <dbaron> lstorset, no
  298. # [18:37] * dbaron Zakim, who is on the phone?
  299. # [18:37] * Zakim sees on the phone: plinss, lstorset, sylvaing, dethbakin, bradk, glazou, Hakon_Lie, Bert, ??P3, [IPcaller], [Mozilla], TabAtkins, [Microsoft], smfr, SteveZ
  300. # [18:37] <lstorset> I will hang up and call again
  301. # [18:37] * Zakim [Mozilla] has dbaron
  302. # [18:38] <Zakim> -lstorset
  303. # [18:38] <TabAtkins> Bert: Where do you get that people expect the video to not scale?
  304. # [18:38] <TabAtkins> howcome: There's tons of video on the web. If you open one in a typical player it won't scale.
  305. # [18:39] <Zakim> +lstorset
  306. # [18:39] * Joins: howcome (howcome@80.203.19.236)
  307. # [18:40] <TabAtkins> TabAtkins: There are places where people provide a single sized <video> and playing videos with different and unpredictable aspect ratios.
  308. # [18:40] <TabAtkins> Leif: Yeah, only difference between the two is that video will scale as contain.
  309. # [18:42] <TabAtkins> TabAtkins: So can we just put "video{image-fit:contain;}", or do we *need* to still vary for other elements?
  310. # [18:42] <TabAtkins> howcome: Yes, for <object>
  311. # [18:44] * Quits: howcome (howcome@80.203.19.236) (Ping timeout)
  312. # [18:44] <TabAtkins> TabAtkins: Other plugins will default to fill, and then size themselves inside the provided box as they need. Do we need to provide different behavior for video in <object>?
  313. # [18:45] <TabAtkins> Leif: If a plugin does the painting, it can size itself as it wants in fill.
  314. # [18:46] <TabAtkins> TabAtkins: Yeah, but is there anything special that we *need* to differentiate between fill and auto for?
  315. # [18:46] <Zakim> -dethbakin
  316. # [18:46] <dbaron> We can put video { image-fit: contain } in the default style sheet for HTML.
  317. # [18:46] <dethbakin> sorry all! i have to leave early today
  318. # [18:47] * Quits: dethbakin (dethbakin@98.234.211.150) (Quit: dethbakin)
  319. # [18:47] * Parts: mollydotcom (mollyh@68.231.162.204)
  320. # [18:48] <TabAtkins> howcome: If you use <object> you don't know whether it's an image, or SVG, or what.
  321. # [18:49] <TabAtkins> Leif: If you fill for SVG it would be overriding the aspect ratio.
  322. # [18:49] <TabAtkins> dbaron: No, what Elika was saying is that SVG would do whatever it wants for sizing. CSS would just provide a content box.
  323. # [18:50] <TabAtkins> Leif: But that would mean that bitmaps and SVGs can potentially size differently with fill. We'd like fill to override SVG's aspect ratio.
  324. # [18:50] <TabAtkins> ChrisL: That's not compatible with what SVG does right now.
  325. # [18:50] <TabAtkins> Leif: We'd pass the information into the SVG.
  326. # [18:51] <TabAtkins> fantasai: I don't think the CSS rules on the replaced box should override anything on the SVG.
  327. # [18:51] <TabAtkins> fantasai: You should pick a viewbox, not the size, for the SVG.
  328. # [18:51] <TabAtkins> fantasai: If you pick a viewbox and don't set width/height, it will scale and act properly with fill/contain/cover
  329. # [18:52] <TabAtkins> Leif: The idea from eric's point of view is that they would replace preserveAspectRatio in SVG.
  330. # [18:52] <TabAtkins> fantasai: Yes, it would replace those *in SVG*. You'd specify it on <svg>, not on <img>.
  331. # [18:52] <TabAtkins> fantasai: Or <object>, or containing document, and expecting SVG to somehow pick that up.
  332. # [18:53] <TabAtkins> Leif: I think it shoudl be possible to do this from CSS.
  333. # [18:53] <TabAtkins> szilles: That means changing the plugin interface.
  334. # [18:53] <TabAtkins> Leif: Isn't CSS already cascaded from the document to SVG?
  335. # [18:53] <TabAtkins> several: no
  336. # [18:53] <TabAtkins> ChrisL: Basically if you have an HTML that links to SVG, it doesn't cascade. But if you have svg-in-html, then it cascades.
  337. # [18:55] <TabAtkins> TabAtkins: I like the distinction that ChrisL outlines, though I do think that we should be able to specify cascading across links.
  338. # [18:55] <TabAtkins> Leif: Yeah, I think we all want that.
  339. # [18:56] <TabAtkins> fantasai: Though with that, you'd still have to specify image-fit on the linked <svg>.
  340. # [18:56] * Bert my browser opens an external viewer for <object data=video>... :-)
  341. # [18:56] <ChrisL> Tab, I'd like the additional values as well to force cascading over a link. I was just saying we don't have that currently despite it being asked for every so often
  342. # [18:57] <fantasai> s/<svg>/<svg> element/
  343. # [18:57] <TabAtkins> howcome: We still need it for <object> for video.
  344. # [18:57] <TabAtkins> TabAtkins: Is there video-in-<object> on the web that isn't using a plugin, and thus subject to the "here's a box, do what you want" rule?
  345. # [18:57] <TabAtkins> szilles: I'm against anything that makes assumptions on impl.
  346. # [18:58] <TabAtkins> howcome: I think if we specify "video is this way, still is that way" is good.
  347. # [18:59] <TabAtkins> TabAtkins: But video-in-<object> uses plugins, and video-in-<video> can be targeted with a UA rule. Where is the video content that needs a special auto value?
  348. # [18:59] <TabAtkins> howcome: I think there is video content in objects and <img>s.
  349. # [19:00] <TabAtkins> fantasai: I think we have a definition for how auto should work *if* it is specified, and a question of whether it should be added.
  350. # [19:00] <TabAtkins> fantasai: So, image-fit auto means "pick the value of image-fit based on the media type; specifically, video/* is contain, everything else as fill"
  351. # [19:00] <fantasai> image-fit: auto means pick a value of image fit based on the media type -- specifically, video/* gets treated as contain, all others as fill, and interaction model defined in >
  352. # [19:01] <fantasai> >
  353. # [19:01] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Feb/0164.html
  354. # [19:01] <fantasai> applies
  355. # [19:02] <TabAtkins> Leif: So could we add it to a spec, with a note that it may get removed?
  356. # [19:02] <fantasai> fantasai: which spec?
  357. # [19:02] <TabAtkins> TabAtkins: Well, it's a simple question to answer first - is there video on the web not done with plugins or <video>?
  358. # [19:02] <TabAtkins> fantasai: Question is which spec?
  359. # [19:02] <TabAtkins> fantasai: I'd like to move it to Images.
  360. # [19:02] <TabAtkins> fantasai: I think it makes more sense, and we can publish changes.
  361. # [19:03] <lstorset> s/Leif/Håkon
  362. # [19:03] <TabAtkins> szilles: That confused it further with things that aren't images.
  363. # [19:03] <TabAtkins> Bert: Replaced Content spec?
  364. # [19:03] <TabAtkins> fantasai: Needs work. ^_^
  365. # [19:03] <TabAtkins> szilles: Can you put a note in the Image spec that this may make more sense in a Replaced Content spec?
  366. # [19:04] <TabAtkins> plinss: Do we have consensus on whether to add it or not?
  367. # [19:04] <TabAtkins> TabAtkins: I still want to see if it's actually needed or not.
  368. # [19:04] <TabAtkins> ChrisL: It seems easier to talk about it in the concrete with it in the spec, so we can talk about it.
  369. # [19:04] <TabAtkins> Bert: I'm in favor of putting it in, with that note.
  370. # [19:04] <Zakim> -Hakon_Lie
  371. # [19:05] <Zakim> -smfr
  372. # [19:05] <Zakim> -[IPcaller]
  373. # [19:05] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
  374. # [19:05] <Zakim> -[Microsoft]
  375. # [19:05] <Zakim> -[Mozilla]
  376. # [19:05] <Zakim> -SteveZ
  377. # [19:05] <Zakim> -glazou
  378. # [19:05] <Zakim> -lstorset
  379. # [19:05] <TabAtkins> RESOLVED: fantasai to add image-fit:auto, and moving the property to Images, marking it as possibly moved again or removed in the future.
  380. # [19:06] * Quits: smfr (smfr@68.183.233.11) (Quit: smfr)
  381. # [19:06] <Zakim> -TabAtkins
  382. # [19:06] <Zakim> -plinss
  383. # [19:07] <Zakim> -sylvaing
  384. # [19:07] <Zakim> -Bert
  385. # [19:07] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
  386. # [19:07] <Zakim> -bradk
  387. # [19:10] * Quits: lstorset (lstorset@213.236.208.22) (Quit: Leaving.)
  388. # [19:11] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
  389. # [19:12] <Zakim> disconnecting the lone participant, ??P3, in Style_CSS FP()12:00PM
  390. # [19:12] <Zakim> Style_CSS FP()12:00PM has ended
  391. # [19:12] <Zakim> Attendees were plinss, +0472369aaaa, lstorset, sylvaing, +1.253.307.aabb, dethbakin, smfr, bradk, glazou, TabAtkins, Hakon_Lie, Bert, [IPcaller], SteveZ, dbaron, [Microsoft]
  392. # [19:16] * Quits: sylvaing (sylvaing@76.104.131.10) (Ping timeout)
  393. # [19:17] <TabAtkins> "SVG in <img> is rendered like 'image-fit: contain'"
  394. # [19:18] <TabAtkins> Does it act differently than if you do SVG in <object>?
  395. # [19:50] * Joins: sylvaing (sylvaing@131.107.0.101)
  396. # [20:00] * Quits: sylvaing (sylvaing@131.107.0.101) (Ping timeout)
  397. # [20:05] * Joins: sylvaing (sylvaing@131.107.0.101)
  398. # [20:49] * Zakim excuses himself; his presence no longer seems to be needed
  399. # [20:49] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  400. # [21:05] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  401. # [21:41] * Quits: sylvaing (sylvaing@131.107.0.101) (Ping timeout)
  402. # [22:02] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
  403. # [22:22] * Joins: Lachy (Lachlan@85.196.122.246)
  404. # [22:22] * Quits: Lachy (Lachlan@85.196.122.246) (Client exited)
  405. # [22:22] * Joins: Lachy (Lachlan@85.196.122.246)
  406. # [23:25] * Joins: shepazu (schepers@128.30.52.169)
  407. # [23:35] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  408. # Session Close: Thu Mar 04 00:00:00 2010

The end :)