W3C home > Mailing lists > Public > www-style@w3.org > March 2010

[CSSWG] Minutes and Resolutions 2010-03-03

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 03 Mar 2010 14:52:59 -0800
Message-ID: <4B8EE84B.9090004@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - Discussed status of CSS3 Lists, given there are known errors in the spec.
     There is no current editor, although fantasai will apply any submitted
     patches to the editor's draft for things that are obviously wrong.
   - Revisited image-fit: auto; issue at Opera's request:
   - RESOLVED: add image-fit:auto to editor's draft, defined as 'contain' for
               video/* and 'fill' for everything else, mark it as possibly
               removed in the future.
   - RESOLVED: Move image-fit and image-position to css3-images, mark as
               possibly moving again to css3-content.

====== Full minutes below ======

   Tab Atkins
   David Baron
   Bert Bos
   Beth Dakin
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Molly Holzschlag (via IRC)
   Brad Kemper
   Håkon Wium Lie
   Peter Linss
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/03/03-CSS-irc
<mollydotcom> I'm here but no phone or Skype access
* mollydotcom will be cheering from the IRC benches
ScribeNick: Tab

CSS3 Lists Issues

   plinss: Anything else on the agenda?
   sylvaing: I submitted comments from a colleague in Japan for CSS3 Lists;
             not sure if that spec is dormant or what.
   sylvaing: They wanted to know what the status was of that spec.
   fantasai: Lists doesn't have an editor right now.
   fantasai: There's a lot of corrections that need to go into there. I made
             some of them that were minor.
   sylvaing: I guess the important thing is to find someone who can assert
             that the suggested changes are correct.
   fantasai: As for correcting obviously wrong things, we can probably just
             do that.
   fantasai: Lists probably needs a review in general, but if we just get a
             patch we can just check those changes into the ED.

image-fit: auto revisited

   plinss: Image-fit talk, revisiting the auto discussion
   howcome: I discussed with our implementors, and they're clear that they
            need 'auto'.
   howcome: I've brought Leif in today.  He's been implementing this stuff.
   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.
   howcome: And then let 'fill' be very explicit that it fills the whole
            rectangle for all media types.
   TabAtkins: Insofar as we need magic values based on media type, I like this.
   Bert: Not all types can scale.  a java applet, frex, can't scale in two
         separate dimensions.
   howcome: True, but for many media types like video it can do so.
   TabAtkins: What would we specify happens for media types that can't scale
              like that?
   howcome: They should fill insofar as it's possible to do.
   ChrisL: Suppose you have something that can only scale proportionately.
           Do you make it act like cover or contain?
   howcome: I don't think we *can* specify all possible details.  Frex,
            widescreen video sometimes has the edges scaled differently
            from the center.
   TabAtkins: So if they *could* scale properly, they must, but if they
              couldn't, it's undefined?
   Bert: How is this different from auto?
   howcome: It would establish a rectangle, and say the content is free to
            do whatever it wants inside of there.
   TabAtkins: Given that we're allowing media to do whatever it wants if it
              can't fill properly, what's the difference with auto?
   howcome: There's a convention that you change the aspect ratio for images,
            but not videos.
   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
   howcome: You could do UA stylesheet and specify different behavior for
             elements, but can't do this for differing media types.
   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.
   dbaron: It sounds like auto is 'whatever you want it to be', not 'what
           you would expect'.  We should define it.
   plinss: We have some auto values that *do* mean 'do whatever the UA wants
           to do'.
   dbaron: Example?
   plinss: (goes to look)
   <lstorset> 'auto' is used in 'overflow' as 'UA decides'
   <dbaron> lstorset, no
   howcome: Scaling video is still a big deal.  It doesn't depend on the
            media type, but on the processor.
   ChrisL: Yeah, you want to treat video differently on lower-powered platforms.
   Bert: You may also want to, say, rotate the video.  That also might not
         work on low-powered devices.
   Bert: Look at communication between image and document.  image gives actual
         width and height, document gives desired width and height.
   Bert: That's all.  You'll need a third value to pass around to say 'auto'.
   howcome: Yeah, you'll need a flag to be passed.  We think it's useful
            enough to do.
   fantasai: Who's going to modify the plugin API?
   howcome: I don't think plugins are relevant here; we're moving away from them.
   szilles: I beg to differ!
   Bert: Steve is right; we don't know the formats that will be used in the
         future, and we designed it so that it can be extended.
   Leif: About the motivation for auto, it was inserted so we could be
         backwards-compatible and still maintain the meaning of fill.

   fantasai: I don't have a problem with auto as long as the model between
             the document and the media doesn't change.
   fantasai: So if auto is just implemented by varying on the content-type
             and aliasing to different image-fit values, that would be fine.
   fantasai: Frex, video 'auto' would act like 'contain'. Images would act
             like 'fill'
   fantasai: I'm not happy with 'auto' meaning 'tell the content something
   sylvaing: I agree.  'auto' should map to one of the existing values.
   howcome: Would you like to describe in the spec which medias map to which
   fantasai: If we're going to do this, then yes, we want it in the spec.
             We want interop.
   fantasai: Of course, if you have a new video plugin, the UA may not know
             that it's a video.
   howcome: Right, so plugins would be considered a media type.
   ChrisL: What would it map to for SVG?
   ChrisL: I'm not happy with something that says "every piece of svg in
           html now breaks".
   fantasai: SVG would work the same as everything else.  We'd draw a box
             based on the intrinsic aspect ratio and image-fit value, and
             then SVG just does whatever it wants inside that viewport.
   fantasai: So for SVG you probably want auto to act like fill.
   fantasai: And then SVG can cover/contain/scale itself based on that box
             and depending on its own attributes.
   fantasai: We should probably be able to distinguish between video and
             images -- they each have their own top-level MIME type.
   szilles: Problem with table is that it gets fixed at some point.
   fantasai: Yeah, but we don't get top-level types very often.
   ChrisL: Animated GIF, like video but can scale?
   szilles: Plugins are an extension mechanism, though, and I don't think
            there's a useful way to standardize this.
   fantasai: I think do the same as SVG - treat 'auto' as 'fill', and then
             tell the plugin 'Hey, render yourself in this nice box'.
   fantasai: Seems the only thing that changes is that video sizes as
             contain, everything else acts like fill.
   fantasai: Was there any other change?
   TabAtkins: The third one was that SVG should be 'none', and keep its
              own intrinsic dimensions.
   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. There's no need to treat it specially.
   ChrisL: It's fine to have different values in CSS to give SVG new
           viewports; SVG already knows how to scale itself.
   ChrisL: It's also fine to have CSS tell SVG specifically how to scale,
           but I don't want it to happen by default.
   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.
   TabAtkins: So the *only* difference with auto is that video will
              scale as contain, everything else scales as fill?
   fantasai: I think so, yeah.
   ChrisL: I see the value there.  It's not wide-open anymore; much more
           implementable and testable.
   szilles: Can anyone precisely answer whether the video/everything else
            is the only relevant distinction for auto?
   howcome: Leif appears to be gone?
   <lstorset> can you hear me?
   <dbaron> lstorset, no
   <lstorset> I will hang up and call again

   Bert: Where do you get that people expect the video to not scale?
   howcome: There's tons of video on the web.  If you open one in a typical
            player it won't scale.
   Bert: That's not a CSS renderer, though.
   TabAtkins: There are places where people provide a single sized <video>
              and playing videos with different and unpredictable aspect
   Leif: Yeah, only difference between the two is that video will scale as
   TabAtkins: So can we just put "video{image-fit:contain;}", or do we
              *need* to still vary for other elements?
   howcome: Yes, for <object>
   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>?
   Leif: If a plugin does the painting, it can size itself as it wants in fill.
   TabAtkins: Yeah, but is there anything special that we *need* to
              differentiate between fill and auto for?
   <dbaron> We can put video { image-fit: contain } in the default style
            sheet for HTML.
   howcome: If you use <object> you don't know whether it's an image, or
            SVG, or what.
   Leif: If you fill for SVG it would be overriding the aspect ratio.
   dbaron: No, what Elika was saying is that SVG would do whatever it wants
           for sizing.  CSS would just provide a viewport.
   Leif: But that would mean that bitmaps and SVGs can potentially size
         differently with fill.  We'd like fill to override SVG's aspect
   ChrisL: That's not compatible with what SVG does right now.
   Leif: We'd pass the information into the SVG.
   fantasai: I don't think the CSS rules on the replaced box should
             override anything on the SVG.
   fantasai: You should pick a viewbox, not the size, for the SVG.
   fantasai: If you set a viewbox and don't set width/height on the SVG,
             it will scale and act properly with fill/contain/cover
   Leif: The idea from eric's point of view is that they would replace
         preserveAspectRatio in SVG.
   fantasai: Yes, it would replace those *in SVG*.  You'd specify it on
             <svg>, not on <img>.
   fantasai: Or <object>, or containing document, and expecting SVG to
             somehow pick that up.
   Leif: I think it should be possible to do this from CSS.
   szilles: That means changing the plugin interface.
   Leif: Isn't CSS already cascaded from the document to SVG?
   several: no
   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.
   TabAtkins: I like the distinction that ChrisL outlines, though I do
              think that we should be able to specify cascading across links.
   Leif: Yeah, I think we all want that.
   fantasai: Though with that, you'd still have to specify image-fit on
             the <svg> element, not its container.
   <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

   howcome: We still need it for <object> for video.
   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?
   szilles: I'm against anything that makes assumptions on impl.
   howcome: I think if we specify "video is this way, still is that way" is good.
   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?
   howcome: I think there is video content in objects and <img>s.
   Peter: It's time to wrap up.
   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.
   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 the interaction model defined in
   howcome: So could we add it to a spec, with a note that it may get removed?
   TabAtkins: Well, it's a simple question to answer first - is there video
              on the web not done with plugins or <video>?
   fantasai: Question is which spec?
   fantasai: I'd like to move it to Images.
   fantasai: I think it makes more sense, and unlike css3-page we can publish
             changes as a Working Draft.
   szilles: That confused it further with things that aren't images.
   Bert: Replaced Content spec?
   fantasai: That spec needs a lot of work. Mostly trimming things out...
   szilles: Can you put a note in the Image spec that this may make more sense
            in a Replaced Content spec?
   fantasai: Sure
   plinss: Do we have consensus on whether to add it or not?
   TabAtkins: I still want to see if it's actually needed or not.
   ChrisL: It seems easier to talk about it in the concrete with it in the
           spec, so we can talk about it.
   Bert: I'm in favor of putting it in, with that note.
   RESOLVED: fantasai to add image-fit:auto, and moving the property to Images,
             marking it as possibly moved again or removed in the future.

Meeting closed.
Received on Wednesday, 3 March 2010 22:53:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:32 UTC