- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 Feb 2010 14:43:23 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary: - Reviewed SVGWG's message on image-fit and image-position: http://lists.w3.org/Archives/Public/www-style/2010Jan/0476.html - RESOLVED: Replaced elements are always clipped to the content box - RESOLVED: Unqualified references to a box in the image-fit/position definitions should be 'content box' - RESOLVED: Whether image-fit & image-position inherit should match the inheritance behavior of SVG's preserveAspectRatio attribute. - RESOLVED: The proposal for a new 'auto' value to 'image-fit' is not accepted. - Briefly discussed animation fill modes and timing functions; further discussion deferred until later. ====== Full minutes below ====== Present: David Baron Bert Bos Beth Dakin Elika Etemad Simon Fraser Sylvain Galineau Daniel Glazman Peter Linss Steve Zilles <RRSAgent> logging to http://www.w3.org/2010/02/24-CSS-irc Scribe: szilles Administrative -------------- Daniel: Light agenda, mostly from last week Daniel: we should start a discussion of coming F2F, agenda items, schedules, attendance Agenda: 1. Follow up on Image Position and Image Fit <glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0476.html Bert: Last weeks discussion did not reach a conclusion on anything wrt Overflow mismatch Bert: Elika proposes and I agree that the rule for "overflow" should be clip the overflowing parts Simon: I can see use cases for scrollbars or the above solution; We could go either way fantasai: The author can put scroll bars on the replace element it self; e.g. a document inside an iframe. Thus there is no particular need for scroll bars on the box into which the replace element goes Simon: I agree with Elika's analysis; clipping makes most sense dbaron: no opinion, still trying to understand it, but willing to live with the clipping proposal RESOLVED: Clipping is the behavior for overflow wrt Missing "none" fantasai: the answer may depend on what the model is for negotiation between the box and the replaced element. I suggested one in a reply <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Feb/0164.html fantasai: The "none' value is asserted as necessary for SVG. I am not sure that this is so. fantasai: If CSS decides on the view box size and SVG decides how to fill it then there is no need for a 'none' value because SVG setting will be used anyway ACTION (all) read Elika's answer above wrt Fit to content or padding box? RESOLVED: content box wrt Don't inherit Daniel: It is suggested to not inherit image-postition and image-fit fantasai: the use case for inheritance is "nested object elements" but it's more important to match SVG's preserveAspectRatio Simon: I am fine with no inheritance Bert: me too RESOLVED: Do what is best for SVG N. B. if what is best for SVG involves no inheritance, then there will be no inheritance ACTION (Elika): Find out what is best for SVG wrt Which module does image-fit go into fantasai: could move this property out of the page module into the images module which is being actively edited Bert: Paged Media should be back into CR as soon as possible fantasai: The catch is that there are a bunch of open issues that will delay getting paged media done Peter: HP is implementing it now and will likely want to push this through, perhaps via me SteveZ: Who will make the changes? fantasai: The problem with making the changes in Paged Media, is that due to references to the CR version from other standards orgs we cannot move the draft back to WD fantasai: The result of this is that the "editor's draft" that is public cannot be reissued so there is a large discrepency between it and the CR draft, since Melinda and I fixed *lots* of issues. SteveZ: it is disconcerting that someone is normatively referencing an out of date document whatever its status fantasai: There was CSS print stuff going on at MIPC and some other org; HP could perhaps provide more detail. SteveZ: can we action HP to tell us what they think the constraints are on the paged media module ACTION (PL): Get information from HP wrt A new 'auto' behavior Bert: I do not like it; I think we can do without it Peter: how do we get the default behaviors without it fantasai: We can say that we assign the box and the content "filler" does what ever it thinks is right fantasai: using the model above, the content filler is given the size of the area to fill and it makes the decision on how to fill it Sylvain: Would 'auto' be the default behavior then? Answer: yes dbaron: Because "object" is so hard to implement, perhpas we should not force that on every other kind of element Sylvain and dbaron: auto should not be the default just because it is good for "object" Daniel: do you agree that a new "auto" value is needed? <dbaron> I think <object> behavior might be a bunch of quirks... and object isn't used very much for any of this. <dbaron> I think the right behavior for <object> might be to switch implementations to doing 'fill'. Sylvain and dbaron: no, we do not agree there is a need RESOLVED: the proposal for a new "auto" value is not accepted Disrete Transitions ------------------- Topic: Applying transitions to properties like visibility <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html dbaron: I think that this is more likely a F2F topic agreed <Zakim> -fantasai * fantasai has to attend an i18n telecon Animation Fill Modes -------------------- <glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0443.html Simon: this would be in addition to animation spec to add a property 'animation-fill-mode' Simon: property allows author to spec whether the effect of the animation extends from now to end of delay period and how it ends dbaron: How does this interact with the animation-iteration-count? Simon: this would apply only after the last interation dbaron: With and iteration count of 3 and a fill-mode of "both" Simon: With a count of 3 and goes forward-backward-forward it applies to the last frame, but if the count were 2 which frame does it apply to dbaron: I like it provided that with even iteration counts are explained <dbaron> I think even iteration counts should probably mean that the from keyframe applies at both ends <dbaron> er, even iteration counts *and* direction:alternate Simon: should the animation spec say anythnig about rendering when the animation event fires? <glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0445.html ACTION (SMFR); Come back with a more detailed proposal Animation Timing Function property ---------------------------------- <smfr> http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html <smfr> ACTION (smfr); Write a more detailed proposal for animation-fill-mode Simon: This overlaps with the 'visibility' discussion Decision: this becomes a topic for the F2F meeting Percentage heights ------------------ <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0286.html dbaron: I would need some time to recall this suggestion Administrative Part II ---------------------- Daniel: Please gather ideas for the F2F agenda Bert: Richard Ishida has volunteered to help edit the Ruby Module and we should invite him to explain what he is doing Daniel: I will arrange an invitation <dbaron> http://www.w3.org/International/wiki/BidiProposal dbaron: There is a bidi proposal that the I18N WG will be discussing. This is aimed at HTML, but is likely to affect CSS as well SteveZ: Should we ask Richard to update us on the bidi propoasl while at our meeting dbaron: that would be good. Adjourn at 9:58 AM PST
Received on Friday, 26 February 2010 22:44:00 UTC