16:56:09 <RRSAgent> RRSAgent has joined #CSS
16:56:09 <RRSAgent> logging to http://www.w3.org/2010/03/03-CSS-irc
16:56:16 <plinss> rrsagent, make logs public
16:56:23 <plinss> zakim, this will be style
16:56:23 <Zakim> ok, plinss; I see Style_CSS FP()12:00PM scheduled to start in 4 minutes
16:56:50 <Zakim> Style_CSS FP()12:00PM has now started
16:56:57 <Zakim> +plinss
16:57:36 <Zakim> + +0472369aaaa
16:58:15 <plinss> zakim, aaaa is lstorset
16:58:15 <Zakim> +lstorset; got it
16:58:16 <Zakim> +sylvaing
16:58:43 <smfr> smfr has joined #css
16:58:48 <dethbakin> dethbakin has joined #css
16:58:59 <mollydotcom> I'm here but no phone or Skype access
16:59:12 <mollydotcom> sorry, limited technology
16:59:20 <Zakim> + +1.253.307.aabb
16:59:30 <oyvind> oyvind has joined #css
17:00:28 <Zakim> +dethbakin
17:00:37 <Zakim> +smfr
17:00:44 <Zakim> +bradk
17:00:54 <glazou> glazou has joined #css
17:01:02 <glazou> hi there
17:01:11 <smfr> morning
17:01:16 <bradk> hello
17:01:27 <Zakim> +glazou
17:01:40 <Zakim> +TabAtkins
17:01:58 <howcome> howcome has joined #css
17:02:32 <Zakim> +Hakon_Lie
17:02:34 <Zakim> +Bert
17:06:27 <TabAtkins> ScribeNick: TabAtkins
17:06:36 <Zakim> +??P3
17:06:52 <TabAtkins> plinss: Anything else on the agenda?
17:07:18 <TabAtkins> sylvaing: I submitted comments from a colleague in Japan for CSS3 Lists; not sure if that spec is dormant or what.
17:07:27 <glazou> Zakim, mute me
17:07:27 <Zakim> glazou should now be muted
17:08:06 <TabAtkins> sylvaing: They wanted to know what the status was of that spec.
17:08:13 <TabAtkins> fantasai: Lists doesn't have an active editor right now.
17:08:28 <TabAtkins> fantasai: There's a lot of corrections that need to go into there.  I made some of them that were minor.
17:08:45 <TabAtkins> sylvaing: I guess the important thing is to find someone who can assert that the suggested changes are correct.
17:09:11 <ChrisL> ChrisL has joined #css
17:09:22 <glazou> hi ChrisL, wb, just got your email
17:09:24 <TabAtkins> fantasai: As for correcting obviously wrong things, we can probably just do that.
17:09:46 <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.
17:10:23 <TabAtkins> plinss: Image-fit talk, revisiting the auto discussion
17:10:33 <glazou> Norwegian slackers :-)
17:10:33 <Zakim> +[IPcaller]
17:10:41 <TabAtkins> howcome: I discussed with our implementors, and they're clear that they need 'auto'.
17:11:02 <TabAtkins> howcome: I've brought Leif in today.  He's been implementing this stuff.
17:11:39 <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.
17:11:51 <TabAtkins> howcome: And then let 'fill' be very explicit that it fills the whole rectangle for all media types.
17:12:00 <Zakim> +SteveZ
17:12:07 <Zakim> +[Mozilla]
17:12:23 <dbaron> dbaron has joined #css
17:12:41 <TabAtkins> TabAtkins: Insofar as we need magic values based on media type, I like this.
17:12:57 <TabAtkins> Bert: Not all types can scale.  a java applet, frex, can't scale in two separate dimensions.
17:13:20 <TabAtkins> howcome: True, but for many media types like video it can do so.
17:13:37 <TabAtkins> TabAtkins: What would we specify happens for media types that can't scale like that?
17:13:44 <TabAtkins> howcome: They should fill insofar as it's possible to do.
17:14:06 <TabAtkins> ChrisL: Suppose you have something that can only scale proportionately.  Do you make it act like cover or contain?
17:15:16 <Zakim> - +1.253.307.aabb
17:15:18 <TabAtkins> howcome: I don't think we *can* specify all possible details.  Frex, widescreen video sometimes has the edges scaled differently from the center.
17:15:40 <TabAtkins> TabAtkins: So if they *could* scale properly, they must, but if they couldn't, it's undefined?
17:15:48 <szilles> szilles has joined #css
17:15:54 <TabAtkins> Bert: How is this different from auto?
17:16:08 <TabAtkins> howcome: It would establish a rectangle, and say the content is free to do whatever it wants inside of there.
17:17:04 <Zakim> -TabAtkins
17:17:25 <Zakim> +TabAtkins
17:17:34 <glazou> wb TabAtkins 
17:17:41 <Zakim> -smfr
17:17:47 <smfr> my turn
17:18:05 <Zakim> +[Microsoft]
17:18:10 <Zakim> +smfr
17:18:44 <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?
17:19:46 <TabAtkins> howcome: There's a convention that you change the aspect ratio for images, but not videos.
17:20:23 <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
17:20:45 <Zakim> -SteveZ
17:20:52 <TabAtkins> howcome: You could do UA stylesheet and specify different behavior for elements, but can't do this for differing media types.
17:21:16 <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.
17:21:36 <TabAtkins> dbaron: It sounds like auto is 'whatever you want it to be', not 'what you would expect'.  We should define it.
17:21:41 <Zakim> +SteveZ
17:21:50 <TabAtkins> plinss: We have some auto values that *do* mean 'do whatever the UA wants to do'.
17:21:56 <TabAtkins> dbaron: Example?
17:22:01 <TabAtkins> plinss: (goes to look)
17:22:10 <lstorset> 'auto' is used in 'overflow' as 'UA decides'
17:22:16 <dbaron> lstorset, no
17:22:24 <glazou> Zakim, unmute me
17:22:24 <Zakim> glazou should no longer be muted
17:22:24 <TabAtkins> howcome: Scaling video is still a big deal.  It doesn't depend on the media type, but on the processor.
17:22:36 <TabAtkins> ChrisL: Yeah, you want to treat video differently on lower-powered platforms.
17:22:44 <Zakim> -SteveZ
17:22:57 <TabAtkins> Bert: You may also want to, say, rotate the video.  That also might not work on low-powered devices.
17:23:01 <Zakim> +SteveZ
17:23:18 <TabAtkins> Bert: Look at communication between image and document.  image gives actual width and height, document gives desired width and height.
17:23:34 <TabAtkins> Bert: That's all.  You'll need a third value to pass around to say 'auto'.
17:23:48 <TabAtkins> howcome: Yeah, you'll need a flag to be passed.  We think it's useful enough to do.
17:23:58 <TabAtkins> fantasai: Who's going to modify the plugin UI?
17:24:08 <TabAtkins> howcome: I don't think plugins are relevant here; we're moving away from them.
17:24:14 <TabAtkins> szilles: I beg to differ!
17:24:27 <dbaron> s/plugin UI/plugin API/
17:24:40 <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.
17:24:59 <glazou> who's speaking now ?
17:25:05 <sylvaing> leif
17:25:07 <glazou> ok
17:25:07 <TabAtkins> Leif: About the motivation for auto, it was inserted so we could be backwards-compatible and still maintain the meaning of fill.
17:25:28 <TabAtkins> fantasai: I don't have a *problem* with auto as long as the model between the document and the media doesn't change.
17:25:43 <arronei> arronei has joined #CSS
17:25:54 <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.
17:26:09 <TabAtkins> fantasai: Frex, video 'auto' would act like 'contain'.
17:26:20 <TabAtkins> sylvaing: I agree.  'auto' should map to one of the existing.
17:26:27 <sylvaing> ...values
17:26:29 <TabAtkins> fantasai: I'm not happy with 'auto' meaning 'tell the content something special'.
17:26:46 <TabAtkins> howcome: Would you like to describe in the spec which medias map to which values?
17:26:58 <TabAtkins> fantasai: If we're going to do this, then yes, we want it in the spec.  We want interop.
17:27:20 <TabAtkins> fantasai: Of course, if you have a new video plugin, the UA may not know that it's a video.
17:27:34 <TabAtkins> howcome: Right, so plugins would be considered a media type.
17:28:16 <TabAtkins> ChrisL: What would it map to for SVG?
17:28:43 <TabAtkins> ChrisL: I'm not happy with something that says "every piece of svg in html now breaks".
17:28:59 <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.
17:29:10 <TabAtkins> fantasai: So for SVG you probably want auto to act like fill.
17:29:27 <glazou> bradk: yt?
17:29:28 <TabAtkins> fantasai: And then SVG can cover/contain/scale itself based on that box depending on its own attributes.
17:29:56 <TabAtkins> fantasai: We should probably be able to distinguish between video and images.
17:30:08 <bradk> ??
17:30:09 <TabAtkins> ChrisL: Animated GIF, like video but can scale?
17:30:21 <TabAtkins> szilles: Problem with table is that it gets fixed at some point.
17:30:28 <glazou> bradk: just answered your quesiton in www-style
17:30:29 <TabAtkins> fantasai: Yeah, but we dont' get top-level types very often.
17:30:46 <TabAtkins> szilles: Plugins are an extension mechanism, though, and I don't think there's a useful way to standardize this.
17:31:06 <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'.
17:31:34 <TabAtkins> fantasai: Seems the only thing that changes is that video sizes as contain, everything else acts like fill.
17:31:47 <TabAtkins> fantasai: Was there any other change?
17:32:48 <TabAtkins> TabAtkins: The third one was that SVG should be 'none', and keep its own intrinsic dimensions.
17:33:08 <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.
17:33:28 <TabAtkins> ChrisL: It's fine to have different values in CSS to give SVG new viewports; SVG already knows how to scale itself.
17:33:48 <TabAtkins> ChrisL: It's also fine to have CSS tell SVG specifically how to scale, but I dont' want it to happen by default.
17:34:28 <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.
17:35:16 <TabAtkins> TabAtkins: So the *only* difference with auto is that video will scale as contain, everything else scales as fill?
17:35:19 <TabAtkins> fantasai: I think so, yeah.
17:35:31 <TabAtkins> ChrisL: I see the value there.  It's not wide-open anymore; much more implementable and testable.
17:36:03 <TabAtkins> szilles: Can anyone precisely answer whether the video/everything else is the only relevant distinction for auto?
17:36:14 <TabAtkins> howcome: Leif appears to be gone?
17:36:18 <lstorset> can you hear me?
17:36:22 <dbaron> lstorset, no
17:36:30 <lstorset> I will hang up and call again
17:36:39 <Zakim> -lstorset
17:36:53 <TabAtkins> Bert: Where do you get that people expect the video to not scale?
17:37:11 <TabAtkins> howcome: There's tons of video on the web.  If you open one in a typical player it won't scale.
17:37:33 <Zakim> +lstorset
17:38:10 <howcome> howcome has joined #css
17:38:58 <TabAtkins> TabAtkins: There are places where people provide a single sized <video> and playing videos with different and unpredictable aspect ratios.
17:39:12 <TabAtkins> Leif: Yeah, only difference between the two is that video will scale as contain.
17:40:54 <TabAtkins> TabAtkins: So can we just put "video{image-fit:contain;}", or do we *need* to still vary for other elements?
17:41:04 <TabAtkins> howcome: Yes, for <object>
17:42:46 <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>?
17:44:12 <TabAtkins> Leif: If a plugin does the painting, it can size itself as it wants in fill.
17:44:38 <TabAtkins> TabAtkins: Yeah, but is there anything special that we *need* to differentiate between fill and auto for?
17:45:19 <Zakim> -dethbakin
17:45:30 <dbaron> We can put video { image-fit: contain } in the default style sheet for HTML.
17:45:33 <dethbakin> sorry all! i have to leave early today
17:45:43 <mollydotcom> mollydotcom has left #css
17:46:38 <TabAtkins> howcome: If you use <object> you don't know whether it's an image, or SVG, or what.
17:47:38 <TabAtkins> Leif: If you fill for SVG it would be overriding the aspect ratio.
17:48:15 <TabAtkins> dbaron: No, what Elika was saying is that SVG would do whatever it wants for sizing.  CSS would just provide a content box.
17:48:53 <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.
17:49:11 <TabAtkins> ChrisL: That's not compatible with what SVG does right now.
17:49:28 <TabAtkins> Leif: We'd pass the information into the SVG.
17:50:00 <TabAtkins> fantasai: I don't think the CSS rules on the replaced box should override anything on the SVG.
17:50:12 <TabAtkins> fantasai: You should pick a viewbox, not the size, for the SVG.
17:50:29 <TabAtkins> fantasai: If you pick a viewbox and don't set width/height, it will scale and act properly with fill/contain/cover
17:50:51 <TabAtkins> Leif: The idea from eric's point of view is that they would replace preserveAspectRatio in SVG.
17:51:06 <TabAtkins> fantasai: Yes, it would replace those *in SVG*.  You'd specify it on <svg>, not on <img>.
17:51:22 <TabAtkins> fantasai: Or <object>, or containing document, and expecting SVG to somehow pick that up.
17:51:33 <TabAtkins> Leif: I think it shoudl be possible to do this from CSS.
17:51:43 <TabAtkins> szilles: That means changing the plugin interface.
17:52:00 <TabAtkins> Leif: Isn't CSS already cascaded from the document to SVG?
17:52:04 <TabAtkins> several: no
17:52:25 <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.
17:54:05 <TabAtkins> TabAtkins: I like the distinction that ChrisL outlines, though I do think that we should be able to specify cascading across links.
17:54:10 <TabAtkins> Leif: Yeah, I think we all want that.
17:55:05 <TabAtkins> fantasai: Though with that, you'd still have to specify image-fit on the linked <svg>.
17:55:15 <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
17:55:37 <fantasai> s/<svg>/<svg> element/
17:55:50 <TabAtkins> howcome: We still need it for <object> for video.
17:56:15 <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?
17:56:24 <TabAtkins> szilles: I'm against anything that makes assumptions on impl.
17:56:39 <TabAtkins> howcome: I think if we specify "video is this way, still is that way" is good.
17:58:14 <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?
17:58:27 <TabAtkins> howcome: I think there is video content in objects and <img>s.
17:58:53 <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.
17:59:19 <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"
17:59:32 <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 >
17:59:35 <fantasai> >
17:59:40 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Feb/0164.html
17:59:41 <fantasai> applies
18:00:45 <TabAtkins> Leif: So could we add it to a spec, with a note that it may get removed?
18:01:02 <fantasai> fantasai: which spec?
18:01:05 <TabAtkins> TabAtkins: Well, it's a simple question to answer first - is there video on the web not done with plugins or <video>?
18:01:14 <TabAtkins> fantasai: Question is which spec?
18:01:21 <TabAtkins> fantasai: I'd like to move it to Images.
18:01:30 <TabAtkins> fantasai: I think it makes more sense, and we can publish changes.
18:01:44 <lstorset> s/Leif/Håkon
18:01:49 <TabAtkins> szilles: That confused it further with things that aren't images.
18:01:58 <TabAtkins> Bert: Replaced Content spec?
18:02:06 <TabAtkins> fantasai: Needs work.  ^_^
18:02:23 <TabAtkins> szilles: Can you put a note in the Image spec that this may make more sense in a Replaced Content spec?
18:02:45 <TabAtkins> plinss: Do we have consensus on whether to add it or not?
18:02:53 <TabAtkins> TabAtkins: I still want to see if it's actually needed or not.
18:03:15 <TabAtkins> ChrisL: It seems easier to talk about it in the concrete with it in the spec, so we can talk about it.
18:03:27 <TabAtkins> Bert: I'm in favor of putting it in, with that note.
18:03:32 <Zakim> -Hakon_Lie
18:03:33 <Zakim> -smfr
18:03:34 <Zakim> -[IPcaller]
18:03:35 <Zakim> -[Microsoft]
18:03:36 <Zakim> -[Mozilla]
18:03:36 <Zakim> -SteveZ
18:03:45 <Zakim> -glazou
18:03:49 <Zakim> -lstorset
18:04:25 <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.
18:05:31 <Zakim> -TabAtkins
18:05:33 <Zakim> -plinss
18:05:34 <Zakim> -sylvaing
18:05:35 <Zakim> -Bert
18:05:46 <Zakim> -bradk
18:10:46 <Zakim> disconnecting the lone participant, ??P3, in Style_CSS FP()12:00PM
18:10:49 <Zakim> Style_CSS FP()12:00PM has ended
18:10:50 <Zakim> Attendees were plinss, +0472369aaaa, lstorset, sylvaing, +1.253.307.aabb, dethbakin, smfr, bradk, glazou, TabAtkins, Hakon_Lie, Bert, [IPcaller], SteveZ, dbaron, [Microsoft]
18:16:10 <TabAtkins> "SVG in <img> is rendered like 'image-fit: contain'"
18:16:42 <TabAtkins> Does it act differently than if you do SVG in <object>?
18:49:33 <sylvaing> sylvaing has joined #css
19:04:10 <sylvaing> sylvaing has joined #css
19:48:24 <Zakim> Zakim has left #CSS
21:20:46 <Lachy> Lachy has joined #css
21:21:26 <Lachy> Lachy has joined #css
22:24:25 <shepazu> shepazu has joined #css
23:48:40 <dbaron> dbaron has joined #css