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

[CSSWG] Minutes and Resolutions 2010-02-24

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 26 Feb 2010 14:43:23 -0800
Message-ID: <4B884E8B.7000909@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Reviewed SVGWG's message on image-fit and image-position:
   - 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
   - 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 ======

   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


   Daniel: Light agenda, mostly from last week
   Daniel: we should start a discussion of coming F2F, agenda items, schedules,

   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

<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
   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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:43 UTC