- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 03 Mar 2010 14:52:59 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
Leif
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
special'.
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
values?
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
ratios.
Leif: Yeah, only difference between the two is that video will scale as
contain.
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.
-dethbakin
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
ratio.
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
http://lists.w3.org/Archives/Public/www-style/2010Feb/0164.html
applies.
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